You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Brett Porter <br...@apache.org> on 2007/08/17 07:31:43 UTC
brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Here's what I did (this is a once off thing, though we really need to
make sure changes are backwards compatible and can handle missing
metadata in the future...)
- run data-management from 1.1-beta-1 to export the build database (I
had to build this from source)
- edit the exported builds.xml to add <installationId>1</
installationId> to each installation (using sequential numbers)
- change name="..." to installationId="..." in each profile by
replacing the name with the corresponding installation ID
- comment out the environmentVariables profile since it would cause a
duplicate PK (maybe a bug in the data management)
- import the database again using data management from 1.1-beta-2.
In case anyone needs it :)
Cheers,
Brett
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Posted by Emmanuel Venisse <em...@venisse.net>.
NEXT_VAL values must be checked in SEQUENCE_TABLE before to to restart continuum
Emmanuel
Emmanuel Venisse a écrit :
> Without sql command:
>
> 1- with data-management: export the db
> java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl
> jdbc:derby:path_continuum_old_db -mode EXPORT
>
> 2- start Continuum to create an empty db (with the good schema)
>
> 3- stop Continuum
>
> 4- import datas with data-management
> java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl
> jdbc:derby:path_continuum_new_db -mode IMPORT
>
> 5- start Continuum
>
> data-management jar is available here:
> http://repo1.maven.org/maven2/org/apache/maven/continuum/data-management-cli/1.1-beta-2/data-management-cli-1.1-beta-2-app.jar
>
>
> Emmanuel
>
> Jesse McConnell a écrit :
>> And this is what I did...
>>
>> I pulled the database someplace that I could run squirrelsql and ran the
>> following sql statements to update the database, then I put the database
>> back into place and started the updated version.
>>
>> ------
>>
>> ALTER TABLE INSTALLATION ADD installation_id integer not null default 0;
>>
>> ALTER TABLE PROFILE_ENVIRONMENTVARIABLES ADD installation_id_eid integer;
>>
>> alter table profiles add builder_installation_id_oid integer;
>>
>> alter table profiles add jdk_installation_id_oid integer;
>>
>> alter table projectdependency add modified_dependencies_id_own integer;
>>
>> alter table projectdependency add modified_dependencies_integer_idx
>> integer;
>>
>>
>> alter table profile_environmentvariables drop foreign key
>> profile_envi2v_fk2;
>>
>> alter table profile_environmentvariables drop foreign key
>> profile_envi2v_fk1;
>>
>> alter table profiles drop foreign key profiles_fk1;
>>
>> alter table profiles drop foreign key profiles_fk2;
>>
>> alter table installation drop primary key;
>>
>> alter table installation add primary key (installation_id);
>>
>> alter table profiles add CONSTRAINT profiles_fk1 foreign key
>> (builder_installation_id_oid) references installation (installation_id);
>>
>> alter table profiles add CONSTRAINT profiles_fk2 foreign key
>> (jdk_installation_id_oid) references installation (installation_id);
>>
>> alter table profile_environmentvariables add CONSTRAINT
>> profile_envi2v_fk2
>> foreign key (installation_id_eid) references installation
>> (installation_id);
>>
>>
>> alter table profile_environmentvariables add CONSTRAINT
>> profile_envi2v_fk1
>> foreign key (id_oid) references profiles (id);
>>
>>
>> ---
>>
>> cheers!
>>
>> jesse
>>
>>
>> On 8/17/07, Brett Porter <br...@apache.org> wrote:
>>> Here's what I did (this is a once off thing, though we really need to
>>> make sure changes are backwards compatible and can handle missing
>>> metadata in the future...)
>>>
>>> - run data-management from 1.1-beta-1 to export the build database (I
>>> had to build this from source)
>>> - edit the exported builds.xml to add <installationId>1</
>>> installationId> to each installation (using sequential numbers)
>>> - change name="..." to installationId="..." in each profile by
>>> replacing the name with the corresponding installation ID
>>> - comment out the environmentVariables profile since it would cause a
>>> duplicate PK (maybe a bug in the data management)
>>> - import the database again using data management from 1.1-beta-2.
>>>
>>> In case anyone needs it :)
>>>
>>> Cheers,
>>> Brett
>>>
>>
>>
>>
>
>
>
>
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Posted by Emmanuel Venisse <em...@venisse.net>.
Without sql command:
1- with data-management: export the db
java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_old_db -mode EXPORT
2- start Continuum to create an empty db (with the good schema)
3- stop Continuum
4- import datas with data-management
java -Xmx512m -jar data-management-cli-1.1-beta-2-app.jar -buildsJdbcUrl jdbc:derby:path_continuum_new_db -mode IMPORT
5- start Continuum
data-management jar is available here: http://repo1.maven.org/maven2/org/apache/maven/continuum/data-management-cli/1.1-beta-2/data-management-cli-1.1-beta-2-app.jar
Emmanuel
Jesse McConnell a écrit :
> And this is what I did...
>
> I pulled the database someplace that I could run squirrelsql and ran the
> following sql statements to update the database, then I put the database
> back into place and started the updated version.
>
> ------
>
> ALTER TABLE INSTALLATION ADD installation_id integer not null default 0;
>
> ALTER TABLE PROFILE_ENVIRONMENTVARIABLES ADD installation_id_eid integer;
>
> alter table profiles add builder_installation_id_oid integer;
>
> alter table profiles add jdk_installation_id_oid integer;
>
> alter table projectdependency add modified_dependencies_id_own integer;
>
> alter table projectdependency add modified_dependencies_integer_idx integer;
>
>
> alter table profile_environmentvariables drop foreign key
> profile_envi2v_fk2;
>
> alter table profile_environmentvariables drop foreign key
> profile_envi2v_fk1;
>
> alter table profiles drop foreign key profiles_fk1;
>
> alter table profiles drop foreign key profiles_fk2;
>
> alter table installation drop primary key;
>
> alter table installation add primary key (installation_id);
>
> alter table profiles add CONSTRAINT profiles_fk1 foreign key
> (builder_installation_id_oid) references installation (installation_id);
>
> alter table profiles add CONSTRAINT profiles_fk2 foreign key
> (jdk_installation_id_oid) references installation (installation_id);
>
> alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk2
> foreign key (installation_id_eid) references installation (installation_id);
>
>
> alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk1
> foreign key (id_oid) references profiles (id);
>
>
> ---
>
> cheers!
>
> jesse
>
>
> On 8/17/07, Brett Porter <br...@apache.org> wrote:
>> Here's what I did (this is a once off thing, though we really need to
>> make sure changes are backwards compatible and can handle missing
>> metadata in the future...)
>>
>> - run data-management from 1.1-beta-1 to export the build database (I
>> had to build this from source)
>> - edit the exported builds.xml to add <installationId>1</
>> installationId> to each installation (using sequential numbers)
>> - change name="..." to installationId="..." in each profile by
>> replacing the name with the corresponding installation ID
>> - comment out the environmentVariables profile since it would cause a
>> duplicate PK (maybe a bug in the data management)
>> - import the database again using data management from 1.1-beta-2.
>>
>> In case anyone needs it :)
>>
>> Cheers,
>> Brett
>>
>
>
>
Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
Posted by Jesse McConnell <je...@gmail.com>.
And this is what I did...
I pulled the database someplace that I could run squirrelsql and ran the
following sql statements to update the database, then I put the database
back into place and started the updated version.
------
ALTER TABLE INSTALLATION ADD installation_id integer not null default 0;
ALTER TABLE PROFILE_ENVIRONMENTVARIABLES ADD installation_id_eid integer;
alter table profiles add builder_installation_id_oid integer;
alter table profiles add jdk_installation_id_oid integer;
alter table projectdependency add modified_dependencies_id_own integer;
alter table projectdependency add modified_dependencies_integer_idx integer;
alter table profile_environmentvariables drop foreign key
profile_envi2v_fk2;
alter table profile_environmentvariables drop foreign key
profile_envi2v_fk1;
alter table profiles drop foreign key profiles_fk1;
alter table profiles drop foreign key profiles_fk2;
alter table installation drop primary key;
alter table installation add primary key (installation_id);
alter table profiles add CONSTRAINT profiles_fk1 foreign key
(builder_installation_id_oid) references installation (installation_id);
alter table profiles add CONSTRAINT profiles_fk2 foreign key
(jdk_installation_id_oid) references installation (installation_id);
alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk2
foreign key (installation_id_eid) references installation (installation_id);
alter table profile_environmentvariables add CONSTRAINT profile_envi2v_fk1
foreign key (id_oid) references profiles (id);
---
cheers!
jesse
On 8/17/07, Brett Porter <br...@apache.org> wrote:
>
> Here's what I did (this is a once off thing, though we really need to
> make sure changes are backwards compatible and can handle missing
> metadata in the future...)
>
> - run data-management from 1.1-beta-1 to export the build database (I
> had to build this from source)
> - edit the exported builds.xml to add <installationId>1</
> installationId> to each installation (using sequential numbers)
> - change name="..." to installationId="..." in each profile by
> replacing the name with the corresponding installation ID
> - comment out the environmentVariables profile since it would cause a
> duplicate PK (maybe a bug in the data management)
> - import the database again using data management from 1.1-beta-2.
>
> In case anyone needs it :)
>
> Cheers,
> Brett
>
--
jesse mcconnell
jesse.mcconnell@gmail.com