When the shards are hosted on different server instances, you can use the “auto-increment-increment” and “auto-increment-offset” MySQL settings (from the replication options group) to get them to generate unique IDs across shards. All instances should use the same increment value (larger than the number of servers) but a different offset.

“Forcing Indices” - MySQL’s emphasis on “FORCE” and other indexing hints is largely a MySQL-specific practice to make up for their extremely crappy optimizer. Using an industrial-strength database like Postgres or Oracle removes most of the need for “hints” (as an example, I used Oracle at many gigs for years in fairly high-volume situations and never had to use an Oracle-specific optimizing hint).

“Commit ORM Objects” - Patently false. The “dirty” list is a list of objects with *potential* changes in them, those which have had some action that marked them as “modified”. The docstring for the descriptor states this, that it’s an “optimistic” check only. You’ll notice that objects/columns that don’t have *actual* changes do not get flushed, even if they had this marking. To detect a net change in an instance before a flush, use the session.is_modified() method (also mentioned in that same docstring). The “dirty” list generally relies upon a fast “modified” flag without digging in to the more expensive comparison which is_modified() performs. But overall, no unnecessary UPDATE statements are issued.

Note that if you are dealing with “pickled” data via PickleType, the comparison is done by default using the result of pickle.dumps(), which can produce different results for essentially the same datastructure, such as a dict, which may be the source of your observation. The comparison method for PickleType can be customized using the “comparator” argument to PickleType() - if you’re pickling dicts and lists, operator.eq is a good choice for this argument.

“Sharding” - the sharding API is mimiced from Hibernate. Sharding assumes you are going to immediately lose most relational advantages if data spans more than one database, and is usually implemented using distinct sessions (i.e., using the shard API creates a false sense of abstraction that’s really not there). We do have one user who has been working on some of the “aggregating” concepts but I think its never going to be possible for this feature to work “transparently”….hence the sharding module is probably going to remain an outlier unless contributors really want to make something huge out of it.

“Server Side Cursors” - for Postgres we support a “server side cursors” mode, but this is used for performance reasons; psycopg2 by default buffers everything on the client side and using this option forces it to use named cursors (and also jumps through many hoops to make the experience transparent). For actual server-side cursor operations, you can get at raw cursors with any database by just calling connection.connection.cursor().

@Valery: Thanks for that, I’ll update it soon!

thanks,
Roy.

Can’t sleep See you in the morning, T