4 ms·

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 mig

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.

douche 10y ago
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.
- caseymarquis 10y ago
  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.
nahname 10y ago
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.
grosbisou 10y ago
> 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.
- prplhaz4 10y ago
  "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.
  - collyw 10y ago
    Me too. When my previous team leader said that, I knew he hadn't bothered to think it through.
- caseymarquis 10y ago
  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.
  - heartbreak 10y ago
    > which monitors when people show up based on their cell MAC That sounds miserable.
    - caseymarquis 10y ago
      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.
krisdol 10y ago
And that, my friends, is how the first company I worked at ended up with a Contact table of 972 columns.
arenaninja 10y ago
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
sontek 10y ago
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.
- caseymarquis 10y ago
  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.
  - sontek 10y ago
    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.
    - caseymarquis 10y ago
      I conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.
nameless912 10y ago
> 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.
- caseymarquis 10y ago
  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.
  - nameless912 10y ago
    I'm gald you acknowledge that! But seriously. Pushing to master, AND updating production...where are your unit tests!?!?
- caseymarquis 10y ago
  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.

douche 10y ago

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.

caseymarquis 10y ago
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.

nahname 10y ago

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.

grosbisou 10y ago

> 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.

prplhaz4 10y ago
"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.
- collyw 10y ago
  Me too. When my previous team leader said that, I knew he hadn't bothered to think it through.
caseymarquis 10y ago
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.
- heartbreak 10y ago
  > which monitors when people show up based on their cell MAC That sounds miserable.
  - caseymarquis 10y ago
    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.

krisdol 10y ago

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

arenaninja 10y ago

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

sontek 10y ago

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.

caseymarquis 10y ago
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.
- sontek 10y ago
  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.
  - caseymarquis 10y ago
    I conceed. For some databases, any adjustment is clearly a major decision with potential consequences. My comment was needlessly inflammatory.

nameless912 10y ago

> 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.

caseymarquis 10y ago
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.
- nameless912 10y ago
  I'm gald you acknowledge that! But seriously. Pushing to master, AND updating production...where are your unit tests!?!?
caseymarquis 10y ago
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.