Nice, thanks for the tips guys! From what I understand, MySQL has some tasty optimisations that are used when the primary key is an int. So once it knows what primary key it's looking for (after looking in the index), it's faster to retrieve the row.
On May 22, 2:50 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On May 22, 2008, at 7:10 AM, Geoff wrote: > > > > > Hi, > > > I have split up my database horizontally and am using UUIDs to > > uniquely identify a row across databases. Using UUIDs as a primary key > > is slow (InnoDB) so I wanted to use the common trick of having a INT > > primary key using auto_increment on each database. This is all fine, > > until sqlalchemy checks its cache of objects after a query to see if > > the object has already been retrieved. This breaks because the primary > > key is not unique across databases when I use an auto_incremented INT. > > > I reckon the solution is going to have to be manually setting the > > field used by sqlalchemy to make the cache decision. Is there any way > > of doing this already, or am I going to have to put it in myself? > > setup the mapper() to have a composite primary key consisting of the > autoincremented integer and the UUID column. Use the primary_key > option on mapper() to achieve this. > > (also why is using a UUID "slow" ? if the column is indexed, the > difference between int/string would be miniscule compared to the fact > that you're using Python and not hardcoded C as the application > platform...) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
