3 ms·

Thanks for the question and I don't think it's that your ignorant. It gets kind of confusing unless you've run into some of these problems in the real world. I'

by dbla 14y ago

Thanks for the question and I don't think it's that your ignorant. It gets kind of confusing unless you've run into some of these problems in the real world. I'll do my best to try and explain the problems that I ran into, which pushed me to start working on this tool. I think storing a version of your schema in VCS is a great idea and it solves part of the problem. If I need to set up a new dev environment I can just run the full schema and I'm good to go. Ok so now I've got my new database set up and one of my teammates, Sally, makes a change. She writes a change script and maybe updates the base schema as well. This means that she has to keep track of the changes she's made all along the way (DevJoist does this for you). But what if another teammate, Joe, also makes a change. Now I've got two change scripts to run, I'm not necessarily sure in what order, and my base schema has a potential conflict. DevJoist won't let you commit a change to the schema unless you've merged in the most recent revision of the schema - and gives you a really slick GUI for doing the merging. The merge tool lets you pick and choose which tables, columns, indexes, column properties etc. you want from each version, and then combines them together. Kind of long winded - sorry, but does that answer your question at all?

pnathan 14y ago
Yes, it does. I'm not convinced that DevJoist's approach is really what I'd want to use, but it explains the problem statement well enough to me.
- dbla 14y ago
  If you have any suggestions for how to solve this problem in a different way I'd love to hear them. I'm struggling with it myself, so if there's an easier way of doing it I'm very interested.
  - pnathan 14y ago
    Honestly, from your problem statement, I would presume that the solution is to use a single branch in your VCS for your deployment, with strict controls on branching and merging, ensuring that a consistent upgrade path is presented to the DBMS at all times. I would probably strive for a tool that would detect conflict and print a report, with the developers themselves managing the merging in the SCM. Although I'm not a DB specialist, I have a profound distrust of GUI tools for this sort of thing; they've died and the DB schema work I was doing was entirely borked. This has happened multiple times across multiple tools. I kind of develop an allergy to certain styles of work in consequence. :-) I know someone who does all his schema work in the DB itself; there's no SCM versioning of the DDL. I don't understand how that's responsible software engineering. No one else can examine the versions, diffs aren't available, there's no record of what it really is, as opposed to the live-coding. (I do a lot of work in Lisp - I learned real quick that you really want files & source control instead of letting things all hang out in the REPL waiting for you to crash it. The database isn't too different in spirit).

by dbla 14y ago

pnathan 14y ago

Yes, it does. I'm not convinced that DevJoist's approach is really what I'd want to use, but it explains the problem statement well enough to me.

dbla 14y ago
If you have any suggestions for how to solve this problem in a different way I'd love to hear them. I'm struggling with it myself, so if there's an easier way of doing it I'm very interested.
- pnathan 14y ago
  Honestly, from your problem statement, I would presume that the solution is to use a single branch in your VCS for your deployment, with strict controls on branching and merging, ensuring that a consistent upgrade path is presented to the DBMS at all times. I would probably strive for a tool that would detect conflict and print a report, with the developers themselves managing the merging in the SCM. Although I'm not a DB specialist, I have a profound distrust of GUI tools for this sort of thing; they've died and the DB schema work I was doing was entirely borked. This has happened multiple times across multiple tools. I kind of develop an allergy to certain styles of work in consequence. :-) I know someone who does all his schema work in the DB itself; there's no SCM versioning of the DDL. I don't understand how that's responsible software engineering. No one else can examine the versions, diffs aren't available, there's no record of what it really is, as opposed to the live-coding. (I do a lot of work in Lisp - I learned real quick that you really want files & source control instead of letting things all hang out in the REPL waiting for you to crash it. The database isn't too different in spirit).