5 ms·

Hibernate has this model built in as well, I believe. https://stackoverflow.com/a/221422 https://stackoverflow.com/a/221422 hbm2ddl.auto=update But it isn’t r

Hibernate has this model built in as well, I believe. https://stackoverflow.com/a/221422 https://stackoverflow.com/a/221422 hbm2ddl.auto=update But it isn’t recommended for production because the automatic diff-based approach can lead to unpleasant surprises. With individual migration files, you always know exactly what they are going to do and can think and plan for how a rollback might be necessary if needed. It’s fair to say that you don’t necessarily need to keep 100 individual files around once they’ve been deployed to every environment for a while and there’s no chance you’d rollback. But I think people typically do this approach because it is simpler and easier than attempting to export the database structure at #100 or whatever and setting a new baseline every few months.

djrobstep 7y ago
I'm certainly not suggesting applying generated diff scripts without reviewing them! In fact, probably the main benefit of the diff approach is that you can rigorously test the outcome, and explicitly confirm a matching schema will result.
- stephenr 7y ago
  How does this possibly work then, if you have to review the scripts first? You're just storing a migration script in the repo still, but it's generated and works against only a single schema "revision"... ?
  - djrobstep 7y ago
    I don't understand the objection here. You want to apply the same migration script against different schemas?
    - stephenr 7y ago
      The same schema, from potentially different points in time. So it's not really applying to different schemas, each single migration script applies against the same state that the previous one produced - but collectively they can be applied against a database from any point in time while that migration system has been used.
      - djrobstep 7y ago
        Again, what exactly are you objecting to? You're just describing how traditional migrations work. There's nothing stopping you saving a sequence of scripts that you use a diff tool to generate, it's just less necessary because you can work against the actual version instead.
        stephenr 7y ago
        ... your comments are both confusing and contradictory. You've simultaneously said that storing scripts is "bad" and that a live "diff" is better, but then also said that those generated "diff" scripts can be reviewed, which means you have to store them. I'm completely aware of using tools to generated scripts by diffing a model schema against a DB, and using a different tool to apply the finalised, reviewed scripts without invoking the "diff" tooling outside of development environments. What I cannot grasp is your convoluted claims that storing scripts is bad, and that diff's can be reviewed before they're applied, without storing them, and will work against some cowboy-esque DB modifications.
        djrobstep 7y ago
        ? Nobody is saying that storing scripts is bad. This is getting silly. I'm skeptical that you even read the original link before attacking it.

djrobstep 7y ago

I'm certainly not suggesting applying generated diff scripts without reviewing them! In fact, probably the main benefit of the diff approach is that you can rigorously test the outcome, and explicitly confirm a matching schema will result.

stephenr 7y ago
How does this possibly work then, if you have to review the scripts first? You're just storing a migration script in the repo still, but it's generated and works against only a single schema "revision"... ?
- djrobstep 7y ago
  I don't understand the objection here. You want to apply the same migration script against different schemas?
  - stephenr 7y ago
    The same schema, from potentially different points in time. So it's not really applying to different schemas, each single migration script applies against the same state that the previous one produced - but collectively they can be applied against a database from any point in time while that migration system has been used.
    - djrobstep 7y ago
      Again, what exactly are you objecting to? You're just describing how traditional migrations work. There's nothing stopping you saving a sequence of scripts that you use a diff tool to generate, it's just less necessary because you can work against the actual version instead.
      - stephenr 7y ago
        ... your comments are both confusing and contradictory. You've simultaneously said that storing scripts is "bad" and that a live "diff" is better, but then also said that those generated "diff" scripts can be reviewed, which means you have to store them. I'm completely aware of using tools to generated scripts by diffing a model schema against a DB, and using a different tool to apply the finalised, reviewed scripts without invoking the "diff" tooling outside of development environments. What I cannot grasp is your convoluted claims that storing scripts is bad, and that diff's can be reviewed before they're applied, without storing them, and will work against some cowboy-esque DB modifications.
        djrobstep 7y ago
        ? Nobody is saying that storing scripts is bad. This is getting silly. I'm skeptical that you even read the original link before attacking it.