

Show HN: DevJoist, database versioning done right - dbla
http://devjoist.com/

======
CoffeeDregs
I don't understand how this is an improvement over Rails' migrations or
Python's South. Or, maybe, what are cases in which I would consider DJ over
built-in migration and schema-management systems?

EDIT: ah, perhaps this is just for systems that don't have such native schema
migration support (e.g. raw PHP apps)? Though I'm still not sure how
comfortable I would be separating schema version from deployed code version.

~~~
dbla
I think the biggest value will be for platforms that don't already have built
in migrations, but hope that eventually some of the tools will be a reason to
use the tool instead of traditional migrations.

The grand vision is that you won't ever have to write migrations again. You'll
just modify your database and DevJoist keeps track of everything. You switch
branches and DevJoist knows to update your database environment accordingly.

------
pnathan
So I'm kind of ignorant here, but why wouldn't you simply have your schemas
stored in vcs and deploy out the upgrade scripts at upgrade time?

~~~
dbla
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
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
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
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).

------
zacharydanger
So, how would I correlate a specific commit in Git to a version on DevJoist?

Until then I'll just use <https://github.com/thuss/standalone-migrations> with
my non-Rails projects.

~~~
dbla
That's a great question. Right now you could include the git version in the
comment of your DevJoist commit. In the future we plan to have much better
integration with git/GitHub and other commonly used developer services like
Heroku. A part of that will be opening up an API so that you can integrate
DevJoist into your workflow however you like.

------
mleaconsulting
Do you have an API I could wire into?

~~~
dbla
Not at the moment, but it's high up on the to-do list along with:

Automatic synching of changes with your databases so that when you save a new
version, your database environment is automatically updated.

Git-style branching.

Versioning of your data (if you're storing any metadata in your db).

