• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

schema comparison/mangement tools.

 
Matt Horton
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you ever had this experience:

Errr, it's Monday. What field did I add to my *hiccup* local schema on Friday at 4 in the morning? I'm supposed to roll-out a few jsps today.


Ummm... neither have I ;).

But, I am curious to see what tool(s) you use to update the production db. I'm in a team of one, so it'd be nice if the solution was freeware...
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35269
383
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matt,
We have operations people do that so we use SQL. I use SQL for the development database too though. It makes for more repeatable changes. That way you don't have to worry about making a mistake or forgetting part of the change.
 
Matt Horton
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne,

Thanks for your reply. So you just write scripts, and then apply them to your local machine and then apply it to the production server? That makes plenty of sense, I guess that I just need to be better organized. After I make a schema change, I invariably have to map it in hibernate (perhaps redo if I have an epiphany about an enum vs a table), write the pages/actions, perhaps map a new field in upload and export jsps and then remember what the schema changes were, to begin with, when I roll them out to the production server.

some schema-diff tool would be really useful.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35269
383
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Matt Horton:
So you just write scripts, and then apply them to your local machine and then apply it to the production server?

Almost. It goes more like:
1) Write script
2) Try it
3) Edit script when things don't work
4) Repeat steps 2 & 3 as needed
5) Release script to CVS
6) All other developers run script on local database
7) Run script in test environment, later environments and then production


That makes plenty of sense, I guess that I just need to be better organized.

Having a lot of developers each with a local database really shows the need for this practice. It's not once that we need to have a record of the state of the database. It's all the time! After you spend a few times trying to figure out why "it works on my machine", the script feels very valuable.


some schema-diff tool would be really useful.

I had to compare schemas once when things got out of synch (between QA and Production.) We just exported the schema and ran diff on it. Since things were pretty similar, this worked fine. There may be a tool; I wouldn't be aware of it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic