Re: brief notes: upgrading 1.1-beta-1 to 1.1-beta-2
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 [EMAIL PROTECTED] 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 installationId1/ 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: Splitting up the Installations form
+1 Wendy, can you file an issue? Olivier, do you want to work on it? Emmanuel Wendy Smoak a écrit : I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts?
RE: Splitting up the Installations form
Hi, Displaying the field (Environment Variable name bla bla ...) only when the user choose the type environnemt variable in the list box ? -- Olivier -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : mardi 4 septembre 2007 05:07 À : continuum-dev@maven.apache.org Objet : Splitting up the Installations form I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts? -- Wendy This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. **
Re: Splitting up the Installations form
Maybe like notifier screens, we can have a process an installation in two steps: screen1: choose the installation type (tool or environment variable) screen2(tool): version, path, parameters... screen2(env var): name, value Emmanuel LAMY Olivier a écrit : Hi, Displaying the field (Environment Variable name bla bla ...) only when the user choose the type environnemt variable in the list box ? -- Olivier -Message d'origine- De : Wendy Smoak [mailto:[EMAIL PROTECTED] Envoyé : mardi 4 septembre 2007 05:07 À : continuum-dev@maven.apache.org Objet : Splitting up the Installations form I think the form for adding a new Installation should be split up into one form for environment variables, and another for the Ant/Maven/JDK installations. The current web UI is confusing, we have a field marked as required when it usually isn't, necessitating a long field label to try to explain the situation. Thoughts? -- Wendy This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. ** Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. **
Re: Splitting up the Installations form
On 9/4/07, Emmanuel Venisse [EMAIL PROTECTED] wrote: +1 Wendy, can you file an issue? Olivier, do you want to work on it? http://jira.codehaus.org/browse/CONTINUUM-1430 I'm not really a fan of the two-step process, but it's already being used for notifiers so we might as well be consistent. *However* in this case I don't think an environment variable qualifies as an installation, and they should really be split up completely. Or, call Installations something else. -- Wendy
