You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@continuum.apache.org by Wendy Smoak <ws...@gmail.com> on 2009/02/06 00:04:18 UTC
Data Management export and import for 1.2.x -> 1.3.x ... do I really
have to?
I've got a dozen Continuum instances to upgrade and I'm not really
looking forward to the process of exporting, importing and then fixing
the next available key values in each one of them.
ISTR someone (Brett?) saying that the only problematic change is a new
column that is required and has no default value.
Can anyone confirm or deny? If it's true, which one is it and what
would I need to modify in a 1.2.x database to make it usable with
1.3.1?
Here's the diff of continuum.xml between 1.2.3 and 1.3.1:
imbrium:mdo wsmoak$ svn diff
https://svn.apache.org/repos/asf/continuum/tags/continuum-1.2.3/continuum-model/src/main/mdo/continuum.xml
https://svn.apache.org/repos/asf/continuum/tags/continuum-1.3.1/continuum-model/src/main/mdo/continuum.xml
Index: continuum.xml
===================================================================
--- continuum.xml (.../continuum-1.2.3/continuum-model/src/main/mdo/continuum.xml) (revision
741334)
+++ continuum.xml (.../continuum-1.3.1/continuum-model/src/main/mdo/continuum.xml) (revision
741334)
@@ -99,6 +99,14 @@
<multiplicity>*</multiplicity>
</association>
</field>
+ <field>
+ <name>projectScmRoots</name>
+ <version>1.1.3+</version>
+ <association>
+ <type>ProjectScmRoot</type>
+ <multiplicity>*</multiplicity>
+ </association>
+ </field>
</fields>
</class>
@@ -128,7 +136,7 @@
<version>1.0.9+</version>
<type>String</type>
</field>
- <field jpox.mapped-by="projectGroup"
jpox.fetch-groups="projectgroup-projects project-build-details">
+ <field jpox.mapped-by="projectGroup"
jpox.fetch-groups="projectgroup-projects project-build-details
project-with-scm-result">
<name>projects</name>
<version>1.0.9+</version>
<association jpox.join="false">
@@ -335,7 +343,14 @@
<type>BuildDefinition</type>
<multiplicity>*</multiplicity>
</association>
- </field>
+ </field>
+ <field jpox.fetch-groups="project-all-details
project-with-scm-details">
+ <name>scmResult</name>
+ <version>1.1.3+</version>
+ <association>
+ <type>ScmResult</type>
+ </association>
+ </field>
</fields>
</class>
@@ -418,6 +433,12 @@
<multiplicity>*</multiplicity>
</association>
</field>
+ <field>
+ <name>sendOnScmFailure</name>
+ <version>1.1.3+</version>
+ <type>boolean</type>
+ <defaultValue>false</defaultValue>
+ </field>
</fields>
<codeSegments>
<codeSegment>
@@ -572,6 +593,7 @@
<version>1.0.9+</version>
<type>int</type>
</field>
+ <!-- TODO: remove -->
<field jpox.fetch-groups="build-result-with-details">
<name>scmResult</name>
<version>1.0.9+</version>
@@ -1008,6 +1030,27 @@
</fields>
</class>
<class>
+ <name>BuildQueue</name>
+ <version>1.1.4+</version>
+ <description><![CDATA[
+ Build queue.
+ ]]></description>
+ <fields>
+ <field>
+ <name>id</name>
+ <version>1.1.4+</version>
+ <identifier>true</identifier>
+ <type>int</type>
+ </field>
+ <field>
+ <name>name</name>
+ <version>1.1.4+</version>
+ <type>String</type>
+ <required>true</required>
+ </field>
+ </fields>
+ </class>
+ <class>
<name>Schedule</name>
<version>1.0.9+</version>
<description><![CDATA[
@@ -1066,6 +1109,14 @@
<version>1.0.9+</version>
<type>String</type>
</field>
+ <field jpox.fetch-groups="schedule-build-queues">
+ <name>buildQueues</name>
+ <version>1.1.4+</version>
+ <association xml.reference="true" stash.part="true"
jpox.dependent="false">
+ <type>BuildQueue</type>
+ <multiplicity>*</multiplicity>
+ </association>
+ </field>
</fields>
</class>
@@ -1222,6 +1273,17 @@
<type>String</type>
<defaultValue>release-output-directory</defaultValue>
</field>
+ <field>
+ <name>numberOfBuildsInParallel</name>
+ <version>1.1.4+</version>
+ <type>int</type>
+ <defaultValue>1</defaultValue>
+ </field>
+ <field>
+ <name>distributedBuildEnabled</name>
+ <version>1.1.4+</version>
+ <type>boolean</type>
+ </field>
</fields>
</class>
@@ -1290,6 +1352,8 @@
public final static int UPDATING = 8;
public final static int WARNING = 9;
public final static int CHECKEDOUT = 10;
+ public final static int UPDATED = 5;
+ public final static int CANCELLED = 11;
// TODO: maybe move these to another class
public static final int TRIGGER_FORCED = 1;
@@ -1527,5 +1591,48 @@
</field>
</fields>
</class>
+
+ <class>
+ <name>ProjectScmRoot</name>
+ <version>1.1.3+</version>
+ <packageName>org.apache.continuum.model.project</packageName>
+ <fields>
+ <field>
+ <name>id</name>
+ <version>1.1.3+</version>
+ <identifier>true</identifier>
+ <type>int</type>
+ </field>
+ <field>
+ <name>scmRootAddress</name>
+ <version>1.1.3+</version>
+ <type>String</type>
+ <required>true</required>
+ </field>
+ <field>
+ <name>oldState</name>
+ <version>1.1.3+</version>
+ <type>int</type>
+ </field>
+ <field jpox.column="scmRootState">
+ <name>state</name>
+ <version>1.1.3+</version>
+ <type>int</type>
+ </field>
+ <field stash.maxSize="8192">
+ <name>error</name>
+ <version>1.1.3+</version>
+ <type>String</type>
+ </field>
+ <field>
+ <name>projectGroup</name>
+ <version>1.1.3+</version>
+ <association xml.reference="true" stash.part="true"
jpox.dependent="false">
+ <type>ProjectGroup</type>
+ </association>
+ <required>true</required>
+ </field>
+ </fields>
+ </class>
</classes>
</model>
--
Wendy
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Emmanuel Venisse <em...@gmail.com>.
On Wed, Feb 11, 2009 at 6:18 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Wed, Feb 11, 2009 at 10:06 AM, Emmanuel Venisse
> <em...@gmail.com> wrote:
>
> > 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.
>
> Yes, I was comparing a fresh db from 1.2.2 to a fresh db from 1.3.1.
> The 'new' columns in 1.3.1 are in the middle when compared to the
> 1.2.2 tables, and I was unsure whether just adding them at the end was
> okay.
>
> Thanks for all the other info on liquibase as well!
No problem.
I'm thinking to use liquibase as a maven plugin to run db migration instead
of our actual tool. Liquibase is really a good tool and it is possible to
run some external program as a changeset so we'll can work on datas between
two changeset if necessary. But this discussion is more for the dev list.
Emmanuel
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Emmanuel Venisse <em...@gmail.com>.
On Wed, Feb 11, 2009 at 6:18 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Wed, Feb 11, 2009 at 10:06 AM, Emmanuel Venisse
> <em...@gmail.com> wrote:
>
> > 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.
>
> Yes, I was comparing a fresh db from 1.2.2 to a fresh db from 1.3.1.
> The 'new' columns in 1.3.1 are in the middle when compared to the
> 1.2.2 tables, and I was unsure whether just adding them at the end was
> okay.
>
> Thanks for all the other info on liquibase as well!
No problem.
I'm thinking to use liquibase as a maven plugin to run db migration instead
of our actual tool. Liquibase is really a good tool and it is possible to
run some external program as a changeset so we'll can work on datas between
two changeset if necessary. But this discussion is more for the dev list.
Emmanuel
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Feb 11, 2009 at 10:06 AM, Emmanuel Venisse
<em...@gmail.com> wrote:
> 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.
Yes, I was comparing a fresh db from 1.2.2 to a fresh db from 1.3.1.
The 'new' columns in 1.3.1 are in the middle when compared to the
1.2.2 tables, and I was unsure whether just adding them at the end was
okay.
Thanks for all the other info on liquibase as well!
--
Wendy
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Emmanuel Venisse <em...@gmail.com>.
On Wed, Feb 11, 2009 at 4:28 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Wed, Feb 11, 2009 at 6:00 AM, Emmanuel Venisse
> <em...@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
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Feb 11, 2009 at 6:00 AM, Emmanuel Venisse
<em...@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?
> 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?
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.
--
Wendy
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Emmanuel Venisse <em...@gmail.com>.
The diff between Continuum-1.2.2 and 1.3.1 generated by liquibase (1.8.1) is
the following:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog/1.8"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://www.liquibase.org/xml/ns/dbchangelog/1.8
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.8.xsd">
<changeSet author="evenisse (generated)" id="1234350082131-1">
<createTable tableName="BUILDQUEUE">
<column name="ID" type="INTEGER">
<constraints nullable="false" primaryKey="true"
primaryKeyName="BUILDQUEUE_PK"/>
</column>
<column name="MODEL_ENCODING" type="VARCHAR(255)"/>
<column name="NAME" type="VARCHAR(255)">
<constraints nullable="false"/>
</column>
</createTable>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-2">
<createTable tableName="PROJECTSCMROOT">
<column name="ID" type="INTEGER">
<constraints nullable="false" primaryKey="true"
primaryKeyName="PROJECTSCMROOT_PK"/>
</column>
<column name="ERROR" type="VARCHAR(8192)"/>
<column name="MODEL_ENCODING" type="VARCHAR(255)"/>
<column name="OLD_STATE" type="INTEGER">
<constraints nullable="false"/>
</column>
<column name="PROJECT_GROUP_ID_OID" type="INTEGER">
<constraints nullable="false"/>
</column>
<column name="SCM_ROOT_ADDRESS" type="VARCHAR(255)">
<constraints nullable="false"/>
</column>
<column name="SCMROOTSTATE" type="INTEGER">
<constraints nullable="false"/>
</column>
</createTable>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-3">
<createTable tableName="SCHEDULE_BUILDQUEUES">
<column name="ID_OID" type="INTEGER">
<constraints nullable="false"/>
</column>
<column name="ID_EID" type="INTEGER"/>
<column name="INTEGER_IDX" type="INTEGER">
<constraints nullable="false"/>
</column>
</createTable>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-4">
<addColumn tableName="PROJECT">
<column name="SCM_RESULT_SCMRESULT_ID_OID" type="BIGINT"/>
</addColumn>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-5">
<addColumn tableName="PROJECTNOTIFIER">
<column name="SEND_ON_SCM_FAILURE" type="CHAR(1)"/>
</addColumn>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-6">
<addColumn tableName="SYSTEMCONFIGURATION">
<column name="DISTRIBUTED_BUILD_ENABLED" type="CHAR(1)"/>
</addColumn>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-7">
<addColumn tableName="SYSTEMCONFIGURATION">
<column name="NUMBER_OF_BUILDS_IN_PARALLEL" type="INTEGER"/>
</addColumn>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-8">
<addPrimaryKey columnNames="ID_OID, INTEGER_IDX"
constraintName="SCHEDULE_BUIL8T_PK" tableName="SCHEDULE_BUILDQUEUES"/>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-9">
<addForeignKeyConstraint
baseColumnNames="SCM_RESULT_SCMRESULT_ID_OID" baseTableName="PROJECT"
constraintName="PROJECT_FK4" deferrable="false" initiallyDeferred="false"
referencedColumnNames="SCMRESULT_ID" referencedTableName="SCMRESULT"/>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-10">
<addForeignKeyConstraint baseColumnNames="PROJECT_GROUP_ID_OID"
baseTableName="PROJECTSCMROOT" constraintName="PROJECTSCMROOT_FK1"
deferrable="false" initiallyDeferred="false" referencedColumnNames="ID"
referencedTableName="PROJECTGROUP"/>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-11">
<addForeignKeyConstraint baseColumnNames="ID_EID"
baseTableName="SCHEDULE_BUILDQUEUES" constraintName="SCHEDULE_BUIMA_FK2"
deferrable="false" initiallyDeferred="false" referencedColumnNames="ID"
referencedTableName="BUILDQUEUE"/>
</changeSet>
<changeSet author="evenisse (generated)" id="1234350082131-12">
<addForeignKeyConstraint baseColumnNames="ID_OID"
baseTableName="SCHEDULE_BUILDQUEUES" constraintName="SCHEDULE_BUIMA_FK1"
deferrable="false" initiallyDeferred="false" referencedColumnNames="ID"
referencedTableName="SCHEDULE"/>
</changeSet>
</databaseChangeLog>
The partial sql for these changesets is:
-- Changeset dbchanges.xml::1234350523950-1::evenisse (generated)::(MD5Sum:
32a19089ed6cae98dc98b71532d536d4)
CREATE TABLE BUILDQUEUE (ID INTEGER NOT NULL, MODEL_ENCODING VARCHAR(255),
NAME VARCHAR(255) NOT NULL, CONSTRAINT BUILDQUEUE_PK PRIMARY KEY (ID));
-- Changeset dbchanges.xml::1234350523950-2::evenisse (generated)::(MD5Sum:
2b18cfd1e86c99f43518f81fc993a83)
CREATE TABLE PROJECTSCMROOT (ID INTEGER NOT NULL, ERROR VARCHAR(8192),
MODEL_ENCODING VARCHAR(255), OLD_STATE INTEGER NOT NULL,
PROJECT_GROUP_ID_OID INTEGER NOT NULL, SCM_ROOT_ADDRESS VARCHAR(255) NOT
NULL, SCMROOTSTATE INTEGER NOT NULL, CONSTRAINT PROJECTSCMROOT_PK PRIMARY
KEY (ID));
-- Changeset dbchanges.xml::1234350523950-3::evenisse (generated)::(MD5Sum:
bcd8289fc7516aa71faf3e8ba070a)
CREATE TABLE SCHEDULE_BUILDQUEUES (ID_OID INTEGER NOT NULL, ID_EID INTEGER,
INTEGER_IDX INTEGER NOT NULL);
-- Changeset dbchanges.xml::1234350523950-4::evenisse (generated)::(MD5Sum:
74a99c58f92f413bf96b1b67c6f331)
ALTER TABLE PROJECT ADD SCM_RESULT_SCMRESULT_ID_OID BIGINT;
-- Changeset dbchanges.xml::1234350523950-5::evenisse (generated)::(MD5Sum:
bbc43a48f0b57b643b1ed99f369b3e55)
ALTER TABLE PROJECTNOTIFIER ADD SEND_ON_SCM_FAILURE CHAR(1);
-- Changeset dbchanges.xml::1234350523950-6::evenisse (generated)::(MD5Sum:
15d5b919e8b160ded2af173acf4c22ac)
ALTER TABLE SYSTEMCONFIGURATION ADD DISTRIBUTED_BUILD_ENABLED CHAR(1);
-- Changeset dbchanges.xml::1234350523950-7::evenisse (generated)::(MD5Sum:
50eddbe1458822ae90504c4a87aa3ae9)
ALTER TABLE SYSTEMCONFIGURATION ADD NUMBER_OF_BUILDS_IN_PARALLEL INTEGER;
-- Changeset dbchanges.xml::1234350523950-8::evenisse (generated)::(MD5Sum:
b142a1e3ab7d6bb326367ba92193d0)
ALTER TABLE SCHEDULE_BUILDQUEUES ADD CONSTRAINT SCHEDULE_BUIL8T_PK PRIMARY
KEY (ID_OID, INTEGER_IDX);
-- Changeset dbchanges.xml::1234350523950-9::evenisse (generated)::(MD5Sum:
8736686c9af81ee33de2f41e95f545)
ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_FK4 FOREIGN KEY
(SCM_RESULT_SCMRESULT_ID_OID) REFERENCES SCMRESULT(SCMRESULT_ID);
-- Changeset dbchanges.xml::1234350523950-10::evenisse (generated)::(MD5Sum:
da19facd1cefbd4e9fdfb01883a886)
ALTER TABLE PROJECTSCMROOT ADD CONSTRAINT PROJECTSCMROOT_FK1 FOREIGN KEY
(PROJECT_GROUP_ID_OID) REFERENCES PROJECTGROUP(ID);
-- Changeset dbchanges.xml::1234350523950-11::evenisse (generated)::(MD5Sum:
cb111ee190e8e9d3290a3a4d476f89)
ALTER TABLE SCHEDULE_BUILDQUEUES ADD CONSTRAINT SCHEDULE_BUIMA_FK2 FOREIGN
KEY (ID_EID) REFERENCES BUILDQUEUE(ID);
-- Changeset dbchanges.xml::1234350523950-12::evenisse (generated)::(MD5Sum:
a9c5b14ba1e967f33f4baf72fded833)
ALTER TABLE SCHEDULE_BUILDQUEUES ADD CONSTRAINT SCHEDULE_BUIMA_FK1 FOREIGN
KEY (ID_OID) REFERENCES SCHEDULE(ID);
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.
Emmanuel
On Tue, Feb 10, 2009 at 10:33 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Thu, Feb 5, 2009 at 4:04 PM, Wendy Smoak <ws...@gmail.com> wrote:
>
> > ISTR someone (Brett?) saying that the only problematic change is a new
> > column that is required and has no default value.
> >
> > Can anyone confirm or deny? If it's true, which one is it and what
> > would I need to modify in a 1.2.x database to make it usable with
> > 1.3.1?
>
> When upgrading from 1.2.x to 1.3.1, trying to use an existing database
> results in:
>
> SQL Exception: In an ALTER TABLE statement, the column
> 'NUMBER_OF_BUILDS_IN_PARALLEL' has been specified as NOT NULL and
> either the DEFAULT clause was not specified or was specified as
> DEFAULT NULL.
>
> However when I look at the model [1] I see...
>
> <field>
> <name>numberOfBuildsInParallel</name>
> <version>1.1.4+</version>
> <type>int</type>
> <defaultValue>1</defaultValue>
> </field>
>
> It looks like there's a default value to me... (and it does default to
> 1 in the Web interface.) Does anyone have an idea why JDO isn't able
> to modify the table?
>
> I don't think I'm willing to try modifying the database for an upgrade
> to 1.3.1, but it would be nice to improve this for 1.3.2+.
>
> [1]
> http://svn.apache.org/repos/asf/continuum/tags/continuum-1.3.1/continuum-model/src/main/mdo/continuum.xml
>
> --
> Wendy
>
Re: Data Management export for 1.2.x -> 1.3.x
Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Feb 11, 2009 at 9:44 AM, DEGARDIN David (CAMPUS)
<da...@oxylane-group.com> wrote:
> I've downloaded the data-management-cli-1.2.4-SNAPSHOT as Wendy
> suggested from ASF snapshot repo:
> http://people.apache.org/repo/m2-snapshot-repository/
Only if you want to play on the bleeding edge. :) If you're going to
use the unreleased data management bits, please come join us on the
dev list to discuss them.
Keep in mind 1.3.1 is only an Alpha, you may want to wait until things
get a little more settled.
--
Wendy
Data Management export for 1.2.x -> 1.3.x
Posted by "DEGARDIN David (CAMPUS)" <da...@oxylane-group.com>.
Hello,
I've downloaded the data-management-cli-1.2.4-SNAPSHOT as Wendy
suggested from ASF snapshot repo:
http://people.apache.org/repo/m2-snapshot-repository/
Now, I want to export my continuum 1.2.2 database. When launching this
command:
java -Xmx512m -jar data-management-cli-1.2.4-20090201.152528-1-app.jar
-buildsJdbcUrl jdbc:mysql://localhost:3306/continuum -mode EXPORT
-directory backups
I got this message:
0 [main] INFO org.apache.maven.continuum.management.DataManagementCli -
Processing Continuum database...
Exception in thread "main"
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException:
Missing:
----------
1) org.apache.derby:derby:jar:10.1.3.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.derby
-DartifactId=derby -Dversion=10.1.3.1 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.derby
-DartifactId=derby -Dversion=10.1.3.1 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -Dreposit
Path to dependency:
1) dummy:dummy:pom:1.0
2) org.apache.derby:derby:jar:10.1.3.1
----------
1 required artifact is missing.
for artifact:
dummy:dummy:pom:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransi
tively(DefaultArtifactResolver.java:324)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransi
tively(DefaultArtifactResolver.java:288)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransi
tively(DefaultArtifactResolver.java:259)
at
org.apache.maven.continuum.management.DataManagementCli.downloadArtifact
(DataManagementCli.java:401)
at
org.apache.maven.continuum.management.DataManagementCli.processDatabase(
DataManagementCli.java:198)
at
org.apache.maven.continuum.management.DataManagementCli.main(DataManagem
entCli.java:170)
I do have derby in my own repo. What's this funny thing again ? Is the
tool working with MySQL ? If not, Wendy (or someone else), did you
managed to upgrade from 1.2.x to 1.3.1 by hand ?
Heeeeeeeeeeeeeeelp !
David
Re: Data Management export and import for 1.2.x -> 1.3.x ... do I
really have to?
Posted by Wendy Smoak <ws...@gmail.com>.
On Thu, Feb 5, 2009 at 4:04 PM, Wendy Smoak <ws...@gmail.com> wrote:
> ISTR someone (Brett?) saying that the only problematic change is a new
> column that is required and has no default value.
>
> Can anyone confirm or deny? If it's true, which one is it and what
> would I need to modify in a 1.2.x database to make it usable with
> 1.3.1?
When upgrading from 1.2.x to 1.3.1, trying to use an existing database
results in:
SQL Exception: In an ALTER TABLE statement, the column
'NUMBER_OF_BUILDS_IN_PARALLEL' has been specified as NOT NULL and
either the DEFAULT clause was not specified or was specified as
DEFAULT NULL.
However when I look at the model [1] I see...
<field>
<name>numberOfBuildsInParallel</name>
<version>1.1.4+</version>
<type>int</type>
<defaultValue>1</defaultValue>
</field>
It looks like there's a default value to me... (and it does default to
1 in the Web interface.) Does anyone have an idea why JDO isn't able
to modify the table?
I don't think I'm willing to try modifying the database for an upgrade
to 1.3.1, but it would be nice to improve this for 1.3.2+.
[1] http://svn.apache.org/repos/asf/continuum/tags/continuum-1.3.1/continuum-model/src/main/mdo/continuum.xml
--
Wendy