5 ms·

Show HN: DevJoist, database versioning done right

24 points by dbla 14y ago

mleaconsulting 14y ago
Do you have an API I could wire into?
- dbla 14y ago
  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).
zacharydanger 14y ago
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 https://github.com/thuss/standalone-migrations with my non-Rails projects.
- dbla 14y ago
  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.
- Sander_Marechal 14y ago
  This. I'm anxiously awaiting some kind of database migration tool that supports easy branching and merging.
pnathan 14y ago
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?
- timnott 14y ago
  I don't want to roll out an entire schema every time I add a feature - just the diffs. It's the schema diffs that devjoist generates. DJ also allows for collaboration among multiple devs working on multiple user stories inside the same project.
- 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.
CoffeeDregs 14y ago
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 14y ago
  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.
raspi 14y ago
When it will support real databases ie. not MySQL?

24 points by dbla 14y ago

mleaconsulting 14y ago

Do you have an API I could wire into?

dbla 14y ago
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).

zacharydanger 14y ago

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 https://github.com/thuss/standalone-migrations with my non-Rails projects.

dbla 14y ago
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.
Sander_Marechal 14y ago
This. I'm anxiously awaiting some kind of database migration tool that supports easy branching and merging.

pnathan 14y ago

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?

timnott 14y ago
I don't want to roll out an entire schema every time I add a feature - just the diffs. It's the schema diffs that devjoist generates. DJ also allows for collaboration among multiple devs working on multiple user stories inside the same project.
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.

CoffeeDregs 14y ago

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 14y ago
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.

raspi 14y ago

When it will support real databases ie. not MySQL?