Mailing-List: contact users-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@continuum.apache.org
Received-SPF: pass (nike.apache.org: domain of emmanuel.venisse@gmail.com
 designates 209.85.220.10 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=kvTJNMila4V1y5/VXAm1ONNAS/4meoWn6Usq08vQ/eSHPVqmLBrgVnh/8Rm55V8pGN
         Al15SQwvmMuprDy3CkKAPlGGK9oYnXj3UjE7CjZKAs8dYekOVJu46kjGJ6+hRJJF3EyS
         jZRLs0qIJ3s994no5pdqEWa1EIfAAt3T6sm54=
MIME-Version: 1.0
In-Reply-To: <adba96190902110728g40cf9e6bmef153a50006ef971@mail.gmail.com>
References: <adba96190902051504l43d1b920ub71cdae232dcfa47@mail.gmail.com>
	 <adba96190902101333r7971afdcjea97f60075e6fdd7@mail.gmail.com>
	 <f345f3480902110500x453d0000s7f0d8d2a6cbdae4d@mail.gmail.com>
	 <adba96190902110728g40cf9e6bmef153a50006ef971@mail.gmail.com>
Date: Wed, 11 Feb 2009 18:06:49 +0100
Message-ID: <f345f3480902110906m15bbb33dm560beb1a9afb38d4@mail.gmail.com>
Subject: Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
	really have to?
From: Emmanuel Venisse <emmanuel.venisse@gmail.com>
To: users@continuum.apache.org
Content-Type: multipart/alternative; boundary=001636c5b84d1fc1e40462a7a141

--001636c5b84d1fc1e40462a7a141
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Feb 11, 2009 at 4:28 PM, Wendy Smoak <wsmoak@gmail.com> wrote:

> On Wed, Feb 11, 2009 at 6:00 AM, Emmanuel Venisse
> <emmanuel.venisse@gmail.com> wrote:
> > The diff between Continuum-1.2.2 and 1.3.1 generated by liquibase (1.8.1)
> is
> > the following:
>
> Cool, can you share the command or process you used to produce this?


To generate the changesets file:

liquibase --driver=org.apache.derby.jdbc.EmbeddedDriver
--url=jdbc:derby:[PATH_TO_NEW_CONTINUUM]/databases/continuum --username=sa
diffChangeLog
--baseUrl=jdbc:derby:[PATH_TO_OLD_CONTINUUM]/databases/continuum
--baseUsername=sa >dbchanges.xml

To generate the sql file:

liquibase --driver=org.apache.derby.jdbc.EmbeddedDriver
--url=jdbc:derby:[PATH_TO_NEW_CONTINUUM]/databases/continuum --username=sa
--changeLogFile=dbchanges.xml updateSQL

If you run it, you'll see it isn't exactly the one I sent because I remove
lines used by liquibase to know what was the latest patch applied.

If you run it directly on the DB without generate the SQL, you can use the
following command:

liquibase --driver=org.apache.derby.jdbc.EmbeddedDriver
--url=jdbc:derby:[PATH_TO_NEW_CONTINUUM]/databases/continuum --username=sa
--changeLogFile=dbchanges.xml update

but it will add liquibase tables.

I used liquibase 1.8.1 because the latest (1.9.0) failed with the
diffChangeLog command but I'm not sure things done in 1.9.0 is important for
us (http://blog.liquibase.org/2009/01/liquibase-190-released.html)


>
> > Maybe it can help you to understand db schema change. For a correct
> update,
> > I think we need to populate some table/column but it's a start.
>
> In a visual inspection of the schemaspy output for 1.2.2 and 1.3.1 the
> other day, I identified these changes:
> new table  CONTINUUM_RELEASE_RESULT
> new table SCHEDULE_BUILD_QUEUES
> new table BUILD_QUEUE
> new table PROJECT_SCM_ROOT
> table PROJECT has new column SCM_RESULT_SCMRESULT_ID_OID
> table PROJECT_NOTIFIER has new column SEND_ON_SCM_FAILURE
> table SYSTEM_CONFIGURATION has new columns DISTRIBUTED_BUILD_ENABLED
> and NUMBER_OF_BUILDS_IN_PARALLEL
>
> That seems to match up with what liquibase found, plus setting up the
> foreign key relationships.  I think I have a handle on *what* changed
> from 1.2.3 to 1.3.1, what I don't understand is how much of this
> change JDO can handle on its own.
>
> Why can't it add the NUMBER_OF_BUILDS_IN_PARALLEL column?  Why does it
> complain that there is no default value, when I see one in the model?


I don't know, maybe a bug in JPOX


>
>
> Another thing I wonder, when I compare the databases for the two
> versions... the new columns appear in the *middle* of tables.  Is it
> okay to append new columns to the end of an existing table?  That
> seems to be what the liquibase sql is doing.


The columns order isn't important. They appears in the middle only for a
fresh db, right? If it isn't, I don't understand which sql command can be
done to insert a column in the middle.


Emmanuel

--001636c5b84d1fc1e40462a7a141--