Moving changesets is possible with liquibase, you just have to do it with care. Check all the changesets in between where you moved it to make sure none of them are depending on the fact that there is no concept_set_id column.
Ben On Mon, Aug 22, 2011 at 10:26 AM, Saptarshi Purkayastha <[email protected]>wrote: > yes, UUID.randomUUID() is Java because postgres doesn't have a core > function for generating UUIDs. There is the popular extension uuid-ossp that > is used for the purpose, but means that implementation will have to install > the extension. We can document that dependency and use of extension... I was > just thinking would be good if it can be avoided for now. > > BTW, just before replying to you... I figured what the problem was. We are > using GenerateUUID to use a single column primary key and not a composite > key like in table concept_set. I later saw that some changesets later, there > is a new column concept_set_id replacing this composite primary key. Thus, I > have moved this changeset above the UUID generation changesets and things > have been working fine. Is this acceptable to change the order of changesets > in liquibase-update-to-latest.xml?? > > I think postgres 9 is doing a better job... > > --- > Regards, > Saptarshi PURKAYASTHA > > My Tech Blog: http://sunnytalkstech.blogspot.com > You Live by CHOICE, Not by CHANCE > > > On 22 August 2011 12:45, Ben Wolfe <[email protected]> wrote: > >> UUID.randomUUID() is in java. Is there a postgres method that you could >> use instead? Should be much faster. >> >> I can't see any reason the GenerateUuid class would be failing. Perhaps >> the updatestatement needs to be cleared? Is there any caching going on by >> preparedstatement, jdbc, or postgres? >> >> Are the changesets faster because of the liquibase upgrade or because >> postgres just does a better job than mysql? >> >> Ben >> >> >> On Sun, Aug 21, 2011 at 7:41 PM, Saptarshi Purkayastha >> <[email protected]>wrote: >> >>> Roger, the ticket <https://tickets.openmrs.org/browse/TRUNK-94> was in >>> Darius's reply to which was below my email. >>> >>> In the meantime, I've also been facing a fairly stupid issue, but can't >>> understand why its happening. On changeset 20090402-1519-concept_set, I'm >>> getting the following: >>> >>> SEVERE 8/21/11 7:29 PM:liquibase: Error executing SQL CREATE UNIQUE INDEX >>> concept_set_uuid_index ON concept_set(uuid) >>> org.postgresql.util.PSQLException: ERROR: could not create unique index >>> "concept_set_uuid_index" >>> Detail: Key (uuid)=(3ef4eba8-f3dc-4bcf-b047-67655062f684 ) is >>> duplicated. >>> >>> For some reason after more than 4 tries, there is always a collision >>> between uuid in that table and they are different each type as generated by >>> UUID.randomUUID(), which in my 100,000 loop unit test does not ever collide >>> but collides in this changeset. Extremely odd... Please help in debugging!! >>> >>> >>> >>> PS: In other news, the changesets from schema-only, demo data execute >>> atleast 5-times faster on postgresql!! I'm excited!! >>> >>> --- >>> Regards, >>> Saptarshi PURKAYASTHA >>> >>> My Tech Blog: http://sunnytalkstech.blogspot.com >>> You Live by CHOICE, Not by CHANCE >>> >>> >>> On 21 August 2011 19:46, Friedman, Roger (CDC/CGH/DGHA) (CTR) < >>> [email protected]> wrote: >>> >>>> I don’t understand why the property is varbinary in that table. There >>>> was an explanation of that at one time here on the list but it was not very >>>> clear about what the problem was that was trying to be solved and why >>>> changing the column to varbinary was the right solution. Cannot find a >>>> ticket addressing issue.**** >>>> >>>> ** ** >>>> >>>> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Saptarshi >>>> Purkayastha >>>> *Sent:* Sunday, August 21, 2011 8:44 AM >>>> *To:* [email protected] >>>> *Subject:* [OPENMRS-DEV] GenerateUuid problem for global_property table >>>> **** >>>> >>>> ** ** >>>> >>>> I see a problem just now while moving to postgres**** >>>> >>>> ** ** >>>> >>>> In the GenerateUuid.java line 131: updateStatement.setInt(2, >>>> ids.getInt(1)); on that table fails. This is because the column is a >>>> varbinary column and not an int. In postgres the global_property tables is >>>> created as:**** >>>> >>>> property character varying(255) NOT NULL DEFAULT ''::character >>>> varying,**** >>>> >>>> ** ** >>>> >>>> Thus, the setInt fails because its not an int column. All other tables >>>> have primary key column as int and doesn't seem to be a problem... but for >>>> this table it's causing problem.**** >>>> >>>> ** ** >>>> >>>> Should I fix this by saying if(tableName.equals("global_property") then >>>> setString??**** >>>> >>>> Or should we add a int primary key column??**** >>>> >>>> ** ** >>>> >>>> There are some places which recommend int primary key columns, but >>>> global_property isn't going to be large table, and hence the question. >>>> **** >>>> >>>> >>>> --- >>>> Regards, >>>> Saptarshi PURKAYASTHA >>>> >>>> My Tech Blog: http://sunnytalkstech.blogspot.com >>>> You Live by CHOICE, Not by CHANCE >>>> >>>> **** >>>> >>>> On 22 July 2011 04:09, Darius Jazayeri <[email protected]> wrote: >>>> **** >>>> >>>> That sounds correct.**** >>>> >>>> ** ** >>>> >>>> -Darius**** >>>> >>>> ** ** >>>> >>>> PS- Burke, Ben, WTF is up with changing global_property.property to >>>> varbinary to make global property names case-sensitive? ( >>>> https://tickets.openmrs.org/browse/TRUNK-94) I've been wondering why >>>> global_property.property shows up oddly in mysql workbench. 15 months later >>>> I'd like to say that I disagree.**** >>>> >>>> ** ** >>>> ------------------------------ >>>> >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> **** >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
