Painless, version-controlled database refactoring

Seriously, where's the painless portion? Apart from a software able to rollback changes from a version to a lower version or apply sql up to a version i see nothing painless here.

Don't get me wrong, you're a pretty orator, but your presentation didn't present me anything painless about database refactoring.

Hi Mathieu,

Sorry to hear that you didn't get any value out of it. I had really hoped everyone in attendance would see the value; however, I suppose I didn't present a compelling enough story for your use cases. I wish I would have gotten a chance to chat with you to find out what your story is so I could have made it more useful for you :(

That being said, thank you so much for being there, and thank you for the kind word on my "oration" :) Very kind of you to say so as I know I could still use a bit of work there as well. Also, thanks for the three thumbs up even though it sounds like you didn't glean much value. Very kind of you indeed.

I really hate that you didn't get much out of it as you could have been sitting in on something else that would have been better for you. Is there anything you think I could have done to make it better for you or did you feel that the tool itself wasn't what you need?

Feel free to hit me up via Twitter (@wilmoore) if you'd like to provide me more feedback.

Kind regards,

--Wil Moore III

BTW, sorry that my comment has a rating associated with it; however, this form doesn't seem to allow me to post a reply comment without adding a rating. I don't want to inaccurately skew the results in either direction so hopefully I can get an admin to correct that.

I would have liked to know ahead of time that this was so tool-specific. If I wanted to know how to get started with liquibase, this was a good talk. But what I was hoping for was a broader discussion of database deployment management under version control. I think the title and description oversold it, that's all. For what the talk turned out to be, it was nicely presented.

@ANONYMOUS,

Thanks for the honest feedback. I'll definitely make the appropriate changes so as to make it more clear that we'll be talking heavily about a tool. That being said, I may actually make this talk less tool specific in the future. Thanks, that's really helpful and thanks for the kind words otherwise :)

Great talk. Entirely worth my time. I can totally see how I can use that. One thing though, more like a point of view rather than a critic -- an although I can extrapolate: as a web programmer, DB revisions are often linked to software revisions, so I would have liked to know what's your take on this. For instance, SQL alters are a subfolder of most of the large web projects I work on. Hints on how to deal with it would have been a plus. But in any case, thanks for your great walkthrough of the liquidbase tool. Cheers!

@Tommy,

Thanks for the feedback. I really appreciate it. You brought up a good subject. In fact, after the talk, a gentleman asked me the very same thing. What I told him was that it depends. Sorry, that sounds kinda hand-wavy right? Well, there are a couple use cases.

There is the development team that has one or more databases that are shared across many applications (think mobile client, desktop client, browser client, etc.). In that case, it makes sense (perhaps) to do it the way I showed in the demo where you have just database stuff in the project; not tied to any one application.

On the other hand, there is the situation where you have a database that is highly coupled to just one application. Sounds like this is your use case (please correct me if I am wrong). This is completely legitimate and in fact, this is how I did it the first time I used Liquibase. I've done it both ways, and both are equally easy to manage.

Perhaps I'll put a project out there that shows this scenario as well. If I do, it will likely be driven by a Makefile as the build tool. If you have any other ideas or thoughts on the matter, definitely hit me up (@wilmoore).

Thanks again :)

Great talk, very good speaker. SQL changes are a pain in our development process (3 dev teams, differents projects, but all in the same database)
I'll have to give a lot of thought on how to implement this but it sure looks like it can help.

Great talk. Very good examples and clear explanations. Brought the subject in an elegant way and described how the solution address which problems and how to address them.