Hacker News Reader

Hacker News

Comment by caseymarquis | Hacker News Reader

Parent Full thread

caseymarquis

Sounds like your framework sucks. With an orm and some sort of json serialization that's literally just:

Put bagel in toaster.

Update the db model.

Add a migration.

Update the viewmodel <==> db model translation in relevant requests.

Get bagel and butter it.

Commit.

Test the migration on a staging db if feeling paranoid, cause it's just adding a column.

Push to master.

Update production.

Take last bite of bagel.

If you aren't also doing the frontend, tell the guy who is to check out the updated swagger docs.

View on HN

> cause it's just adding a column

This kind of mentality is why most applications are shit and broken. And why most hires are worthless.

And everyone is not working on a cookie cutter over-bloated rails website. Sorry but this kind of remark simplifying our job always pisses me off.

"can't we just" is top of the list as a trigger for my bullshit detector.

In a system of any complexity, changing your data model is an activity that requires due diligence to mitigate any downstream risk.

Me too. When my previous team leader said that, I knew he hadn't bothered to think it through.

At my company, we have one software package it costs on average a quarter million USD to install per enterprise customer. It gets about 100,000 records added per day in some deployments. We test our migrations on those systems and have a dedicated data service which is the only thing which can touch any given customer database. We are paranoid about those systems.

We also have throwaway apps like an internal time clock system which monitors when people show up based on their cell MAC.

Latter case: Adding a checkbox is easy.

Former case: Adding a checkbox is easy but we have to test it first.

> which monitors when people show up based on their cell MAC

That sounds miserable.

It's voluntary. We're all salary and a portion of our bonus is based on hours worked. When I did the occasional 100 hour week (also voluntary; I work on fun stuff) and forgot to log my hours, I would get credit for it, but there wasn't a direct metric for compensation.

We started adding in other employees in multiple departments cause they liked it better than manually tracking.

And that, my friends, is how the first company I worked at ended up with a Contact table of 972 columns.

So simple anyone with at least three to five years experience and 4 months on the project can do it! Starting salary is 120k, relo to SF required.

> Push to master. Update production.

You monster. You fucking monster.

The reality is that ORMs are a huge headache and a chunk of dependency and magic that make some people uncomfortable. Even though I make more mistakes writing the glue code between SQL and my backend than I would with the ORM, I know how every bit of that code works, and I've reduced significantly the magic I have to deal with in order for my code to work (basically, just the database driver since I own everything else).

ORMs are a huge surface to secure, tune, and understand, and I think that it's unfair to tell someone their app sucks just because they refuse to use one.

I didn't say his code was bad. I meant whatever they're using for libraries must be a pain to work with. I was overly general, should have used different language, and what I said was flat out wrong for some environments.

I'm gald you acknowledge that!

But seriously. Pushing to master, AND updating production...where are your unit tests!?!?

This is definitely a common use case and very valid for smaller applications. If I were you though I would avoid applying your experience on smaller scale applications as a way to say that everyone who can't do that are using bad frameworks.

Once your application reaches a certain scale there is a huge chance that generated migration could lock a table for minutes to hours which isn't acceptable.

We allow developers to run generated migrations in dev/testing environments but when its time to go to staging we evaluate the changes made and check query plans and figure out what type of locking is going to happen and how long it would take it prod. There is very few times the migrations Django or Rails generate are acceptable at our scale in production.

I think you're correct. I was out of line by being too general.

For our large scale applications we back up the database and have required down time from our customers while doing a major migration.

Everything isn't always simple. But adding a check box in 90% of cases usually is.

Adding a check box in a relational database most likely involves running ALTER TABLE to introduce a new column which in most relational databases locks the table.

Now lets say you are doing 15,000 requests per second on that table.... is preventing those from executing acceptable in your system? Its not in mine which is why we don't run ORM generated migrations.

I conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.

Our framework does kind of suck...

We're also not doing the common website/webapp thing, but rather on-premise enterprise software. So we have to update installers too, and be relatively paranoid about updates, because it is intensely painful when we have a bad update with one of our customers.

I feel that. We have the same deployment model and customers pay hundreds of thousands of dollars to have our systems installed. When our systems go down individual companies can lose tens of thousands of dollars in an hour. More than that under some circumstances. We always test migrations thoroughly on those systems. Even simple ones.

On our less important software that'd just be a direct push to production though.

If you're working on a database without any data in it, sure.

When your tables have millions of records for enterprise customers, it's significantly more involved than you describe

Reply on news.ycombinator.com