Comments on: Migrations for Java http://blog.f12.no/wp/2009/01/03/migrations-for-java/ Running around in the maze Sun, 05 Sep 2010 08:55:55 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Dazed & Confused » Java migrations tools http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78730 Dazed & Confused » Java migrations tools Wed, 24 Mar 2010 08:37:28 +0000 http://blog.f12.no/wp/?p=878#comment-78730 [...] I have written some blog posts on this already, and in relation to the talk and things at work I did a quick search for Java migration tools. DBDeploy I have used earlier, but there are now a couple of other contenders. Here’s my list so far of tools that work on sql deltas that can be checked into SCM: [...] [...] I have written some blog posts on this already, and in relation to the talk and things at work I did a quick search for Java migration tools. DBDeploy I have used earlier, but there are now a couple of other contenders. Here’s my list so far of tools that work on sql deltas that can be checked into SCM: [...]

]]> By: Dazed & Confused » Agile deployment talk retro http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78418 Dazed & Confused » Agile deployment talk retro Fri, 27 Mar 2009 16:33:34 +0000 http://blog.f12.no/wp/?p=878#comment-78418 [...] Migrations for Java [...] [...] Migrations for Java [...]

]]> By: Anders http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78318 Anders Thu, 12 Feb 2009 11:43:37 +0000 http://blog.f12.no/wp/?p=878#comment-78318 I can see your dilemma, but like most things that revolve around this it is more of a process question than a technical question. First off, if you have two projects that use the same DB with no anti-corruption layer between them (this could be views) you should always deploy them together. The "independence" if they are relying on the same DB is merely virtual, and trying to handle them independently is just going to cause you trouble. I also find the notion that you can test fixes in separation a bit utopian. Within one project this can be obvious, but by using the same DB for the two projects they are quite coupled anyway. Because fixes can (not always do) build on each other, and in this case you will actually have two DB deltas where one always must run before the other (55 before 56 etc.). As always there is no easy answer. :) Let me know if there's anything else. I can see your dilemma, but like most things that revolve around this it is more of a process question than a technical question.

First off, if you have two projects that use the same DB with no anti-corruption layer between them (this could be views) you should always deploy them together. The “independence” if they are relying on the same DB is merely virtual, and trying to handle them independently is just going to cause you trouble.

I also find the notion that you can test fixes in separation a bit utopian. Within one project this can be obvious, but by using the same DB for the two projects they are quite coupled anyway. Because fixes can (not always do) build on each other, and in this case you will actually have two DB deltas where one always must run before the other (55 before 56 etc.).

As always there is no easy answer. :) Let me know if there’s anything else.

]]> By: shaunybee http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78317 shaunybee Thu, 12 Feb 2009 11:34:38 +0000 http://blog.f12.no/wp/?p=878#comment-78317 Thanks for the [prompt] response. OK - a separate project is probably the best way to go since like I said we have several dbs and some are shared between applications. It gets tricky when say 'developer a' makes changes in Java 'project x' for shared 'db 1', while 'developer b' makes changes in Java 'project y' for shared 'db 1' and then the PM wants to deploy [tp prod] both sets of changes at the same time - but test teams want to test the changes separately (i.e. the change set scripts are independent), and 'developer a' may not have spoken with 'developer b' ... you can imagine the rest :) Joy! Thanks again. S. Thanks for the [prompt] response. OK – a separate project is probably the best way to go since like I said we have several dbs and some are shared between applications. It gets tricky when say ‘developer a’ makes changes in Java ‘project x’ for shared ‘db 1′, while ‘developer b’ makes changes in Java ‘project y’ for shared ‘db 1′ and then the PM wants to deploy [tp prod] both sets of changes at the same time – but test teams want to test the changes separately (i.e. the change set scripts are independent), and ‘developer a’ may not have spoken with ‘developer b’ … you can imagine the rest :) Joy! Thanks again. S.

]]> By: Anders http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78316 Anders Thu, 12 Feb 2009 11:18:11 +0000 http://blog.f12.no/wp/?p=878#comment-78316 We just created a separate Maven project which of course is in SVN. Then we placed the sql stuff in src/sql. Maven doesn't have a concept of SQL files or databases, so deciding on the path is up to you. The paths you choose will be reflected in the Ant parts of the setup. Also see http://blog.f12.no/wp/2009/01/24/the-new-guy-and-his-database/ A, We just created a separate Maven project which of course is in SVN. Then we placed the sql stuff in src/sql.

Maven doesn’t have a concept of SQL files or databases, so deciding on the path is up to you. The paths you choose will be reflected in the Ant parts of the setup.

Also see http://blog.f12.no/wp/2009/01/24/the-new-guy-and-his-database/

A,

]]> By: shaunybee http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78315 shaunybee Thu, 12 Feb 2009 10:30:57 +0000 http://blog.f12.no/wp/?p=878#comment-78315 Hi, I am looking at using such a system as this - however not sure where the sql base and delta files should be kept in our SCC system (SVN) - should database files be in their own repository with sub-folders per database (we have several databases) or should scripts be with the Java code projects themselves. The issue I am thinking is that we use Maven 2 and there isn't a standard project structure to include database scripts in maven (I think?) - unless they should go in src/main/resources? Thanks in advance for any ideas... we desperately need to re-gain control of the databases/versions and this all sounds great :) Hi,
I am looking at using such a system as this – however not sure where the sql base and delta files should be kept in our SCC system (SVN) – should database files be in their own repository with sub-folders per database (we have several databases) or should scripts be with the Java code projects themselves. The issue I am thinking is that we use Maven 2 and there isn’t a standard project structure to include database scripts in maven (I think?) – unless they should go in src/main/resources?
Thanks in advance for any ideas… we desperately need to re-gain control of the databases/versions and this all sounds great :)

]]> By: The new guy and his database at Dazed & Confused http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78257 The new guy and his database at Dazed & Confused Sat, 24 Jan 2009 16:47:47 +0000 http://blog.f12.no/wp/?p=878#comment-78257 [...] is a followup to two previous articles about Agile databases and Migrations for Java. It tries to examplify some of the stuff I talk about in those two articles. Here we go [...] [...] is a followup to two previous articles about Agile databases and Migrations for Java. It tries to examplify some of the stuff I talk about in those two articles. Here we go [...]

]]> By: Willie http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78248 Willie Mon, 12 Jan 2009 08:24:12 +0000 http://blog.f12.no/wp/?p=878#comment-78248 I've never used DBDeploy for database migrations - I'm sure it's really good. For a while now I've been hooked on Liquibase (www.liquibase.org) - it's really really good. I think the key is the process, not so much the tool. I get a 100% productivity jump using *any* automated tool for upgrading/downgrading databases. I’ve never used DBDeploy for database migrations – I’m sure it’s really good. For a while now I’ve been hooked on Liquibase (www.liquibase.org) – it’s really really good. I think the key is the process, not so much the tool. I get a 100% productivity jump using *any* automated tool for upgrading/downgrading databases.

]]> By: Redesign is not going to save you at Dazed & Confused http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78247 Redesign is not going to save you at Dazed & Confused Sat, 10 Jan 2009 15:25:22 +0000 http://blog.f12.no/wp/?p=878#comment-78247 [...] Archives « Migrations for Java [...] [...] Archives « Migrations for Java [...]

]]> By: anderssv (Anders Sveen) http://blog.f12.no/wp/2009/01/03/migrations-for-java/comment-page-1/#comment-78298 anderssv (Anders Sveen) Sat, 03 Jan 2009 10:11:04 +0000 http://blog.f12.no/wp/?p=878#comment-78298 blog: Migrations for Java http://tinyurl.com/axy2q9 blog: Migrations for Java http://tinyurl.com/axy2q9

]]>