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 >> > > _________________________________________ 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]
