On Dec 2, 2007, at 6:38 PM, Simon Wittber wrote:
> > On Dec 3, 3:31 am, Michael Bayer <[EMAIL PROTECTED]> wrote: >> On Dec 1, 2007, at 11:10 PM, Simon Wittber wrote: >>> Is there any way around this issue, other than explicitly calling an >>> id_generator function, and setting the primary key before the >>> instance >>> gets passed to the shard chooser? >> >> I would call id_generator() *within* shard_chooser() if the pk is not >> available, that way shard_chooser is guaranteed to have the info that >> it needs. other options include MapperExtension.before_insert() but >> I dont see that as any more convenient than just within >> shard_chooser. > > Ah good idea. As a side point, I've realised that choosing a shard > based on an integer PK is probably not the best idea. In this > particular case, it's better to choose a shard based on the first > letter of the user_name field, as that lets me group similar > user_names in the same shard, and therefore continue to use a unique > constraint on that same field. > > This sharding stuff certainly changes the way I think about relational > db systems. > I cant speak authoritatively on the best sharding algorithms since i dont have much direct experience with them. The sharding API is modeled after Hibernate's existing API as well as what users were asking for, and so far we've had one other user I know of working with it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
