Re: [Liquibase-user] Re commendation
On Mon, May 18, 2009 at 4:54 PM, jfrapper wrote: > How should I hook this into the Liquibase update process. I really dont > want to put it at the end of each differential file. Suggestions?! I usually put this kind of thing in my Ant script, after the call to Liquibase update task. Cheers, Diego -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Moving to a forum system
I guess it is possible to receive emails for every new topic posted to a board by clicking the "Notify" button on the board. I would recommend that for the good old liquibase-user fans like me... Diego On Wed, Apr 29, 2009 at 5:15 AM, Voxland, Nathan wrote: > I have set up a LiquiBase Community Forum at http://www.liquibase.org/forum > that will take the place of the mailing lists. > > My hope is that it will lead to a lower bar for entry to ask or answer > questions, allow better searching of past messages, and more. > > Please check it out, register there, and let us know your thoughts. > > Nathan -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Res: Keeping the order of execution on local databases
> Developer A should have merged from the SCM, then done a complete > re-test, including rebuilding the database. At least, that's how I see it. Yep, that is another solution I'd forgotten, but it is also one I was trying to avoid. In general, I would not recommend rebuilding the database because of these problems: - When you constantly rebuild your database, you are not testing data migration, which is one of the main advantages of using a tool such as Liquibase. - It forces all the developers and testers to loose their test data. When test data has been inserted during the development or testing of a new feature or something like that, it may not be so easy to automatically reinsert it into the database. Loosing that data can be extremely inconvenient. - Considering a large database, a rebuild can be potentially slower than a simple update. > It looks to me like the problem in this scenario is NOT recreating a > database from the ground up for testing. I constantly struggle with > this problem with our QE department. They want to keep pulling their > data forward as changes occur, instead of creating a script that will > regenerate their data sets. The problems that arise during development and testing are the same that will arise during the migrations of your end users databases. As I said, identifying these problems early is one key feature of a database change management tool. To achieve this, you must favor updating over rebuilding. > There is always the potential for problems > arising from data that is no longer valid after a code/database change. Data should always be valid after a code/database change. If it is not, then you are probably not migrating your data correctly. Cheers, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Keeping the order of execution on local databases
Hi all, here is an interesting case that happened during our Liquibase/changeSet development. I was already aware of this possibility, but this was the first time that it really happened in our environment. In short, the problem is that, when developers hold their changeSets locally for a few days prior to commit, they do not guarantee the order of execution. The best way to explain this is by giving an example: 1. Developer 'A' creates a changeSet 'Ca' and executes it against his local database. Because the developer needs to modify the Java code accordingly and test the feature, he keeps the changeSet locally a few days prior to commit. The changeSet executes an INSERT in a popular table: INSERT INTO product (product_id, description, color, ... 2. Developer 'B' identifies a column of the same popular table that is no longer being used by the application and decides to remove it. He then creates, tests and commits a changeSet 'Cb' that removes the column: ALTER TABLE product DROP COLUMN color; 3. It's time for developer A to commit his changeSet. To be sure everything is ok, he makes an update from the repository, downloads Cb, and executes Liquibase. Since he has previously executed Ca during the tests (which makes this step useless anyway), everything goes fine. He then commits Ca. 4. Developers B and C make an update from repository, download Ca, and execute Liquibase. This execution fails, because Ca cannot be run after Cb. I know this may not be a common problem, even so, since dealing with changeSet dependencies is the main Liquibase feature, I still think it is an interesting case. Some solutions I can think of include: not bothering with this at all, using a rollback/update strategy to ensure the order of execution locally, and using a central database to test the changeSets prior to commit. Any ideas about this? Regards, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Res: Does anyone use Java 1.4?
I don't care much about this, but I think that anyone who still needs Java 1.4 can download a previous version of Liquibase and use it, right? Diego - Mensagem original > De: Paul Keeble > Para: liquibase-user@lists.sourceforge.net > Enviadas: Segunda-feira, 20 de Abril de 2009 11:11:23 > Assunto: Re: [Liquibase-user] Does anyone use Java 1.4? > > > If only it was that easy! 1.4 is the backbone of huge numbers of application > servers still in active use out there, because JavaEE only recently got > updated. > These are also the environments where a tool like liquibase comes in most > useful. I'd love to see the death of Java 1.4 as much as everyone, but I > think > support is necessary for a little while. > > Putting out a deprecatation warning now would seem like a reasonable > approach, > and then killing support in something like 6 months to a year to give people > time to migrate. > > Paul Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Res: Consolidating Change scripts
Marco, we are currently using an approach that could make your dba happier: every release, we make an export of the database and use it as a "seed" for the next release. This way, we avoid having to re-execute all of the past changeSets everytime we need a fresh database. I guess this export/import process will also do some sort of "clean up" in your database. Hope that helps, Diego PS.: If he does not get happier... get rid of him! ;-) De: "Voxland, Nathan" Para: liquibase-user@lists.sourceforge.net Enviadas: Quarta-feira, 1 de Abril de 2009 18:24:31 Assunto: Re: [Liquibase-user] Consolidating Change scripts I don’t think that executing a large number of changes is going to corrupt your database metadata, but performance begins to degrade over time. Unfortunately there is not a great automated way to combine changesets. There is the diff tool (http://www.liquibase.org/manual/diff) which can combine a database in the old format with a database in the new format and generate a list what needs to be done to get from one to the next, but it doesn’t cover everything and diffs in general have problems (see http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html). If you have just a few changes you may be able to handle it, if you have a lot you can easily miss things. Besides, you have tested your updates during development as individual changes, and you may introduce new errors when you rewrite them. I would recommend keeping the changesets as originally written except in extreme performance causing cases where you can modify them by hand. Nathan From:Reimann, Marco [mailto:marco.reim...@hypoport.de] Sent: Wednesday, April 01, 2009 10:03 AM To: liquibase-user@lists.sourceforge.net Subject: [Liquibase-user] Consolidating Change scripts Hi, is there a way for liquibase to consolidate changes while generating sql change scripts? By default, liquibase generates for each change a separate ddl statement. During the course of development of a production release there will be many changes, some of which may touch the same columns, even reversing earlier changes in some cases. (creating table a, adding a column, renaming it, maybe dropping it again, etc.) Our dba fears that that many changes could eventually corrupt the metadata of our database. To avoid that, these changes would have to be consolidated or aggregated. That means that a script would be created that contains only the necessary statements to change the production database from the last release to the current one, ommitting all redundant changes and touching each column only once. Currently we plan to do this by hand, which will be a tedious and error-prone process. Could this be be done automatically by liquibase? I think, it has all necessary base data for this process (the liquibase change xmls itself). What are your thoughts on this? Regards, Marco Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
David C. Hicks escreveu: > Whether you choose to modify change sets during the Dev-QA cycle really > depends on your internal process, I would say. > > On 3/31/09 8:53 PM, Anastasios Angelidis wrote: >> How about in Dev-QA cycle, should the changeset be fixed or should a new >> changeset be made to fix the problem? As David said, it depends. However, I prefer and recommend the idea of always creating a new changeSet. I see only one situation in which it is imperative to modify a changeSet: when there is a bug in the changeSet that causes data loss. For example, if a developer writes a changeSet to split one table in two, drops the original columns, and forgets to migrate the data. Now you have no choice, because the data is gone and there is no way to write a new changeSet to correct this. The only thing to do is to correct the data migration in the original changeSet. To reduce the occurrences of this kind of problem, it is nice to make frequent migrations using test data and/or real world populated databases. Diego -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Res: Starting DB from scratch
> If you follow the best practices. That means that for every new > changeset... Will you have a new file which wont be comparable against > an old one? Usually you create a new changeSet for every change to be applied to the database. Except for rare cases such as when you are starting a brand new schema, you will most probably want to avoid (like hell) modifying changeSets. Now, about organizing your changeSets, you have three options: put all of them in a single changelog file; organize them according to feature/module using the include tag; use the one-changeSet-per-file approach (I personally like this one!). Notice that, by following this, the only comparison you can make is checking whether you have new changeSets or not. You dont need all of them being in the same changelog file to do this. If what you wanted was to compare different states of a table definition such as in your previous "CREATE TABLE" example, then you are right: there is no way to compare two versions of the same table definition. From my experience I would say that you usually dont need it. > If you use one changelog.xml you can dif it, but if you use separate > ones you can't diff them directly? Yep, that is right. Usually you dont need to diff. > Then again one changelog.xml can become huge. Right again. That is why I like separating one changeSet per changelog file. Most people separate changeSet according to feature/module though. Hope that helps, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
