I don't understand the M-to-M use case. Do you just mean that it makes the order of a list of related objects deterministic? If so I would submit that the Right Thing would be to make the related objects a set rather than a list; let the user create a sorted list himself if he really wants it (presumably he will have a criterion that makes sense), but imposing an arbitrary order on something that is inherently setlike doesn't make sense to me.
On 12/31/05, Michael Bayer <[EMAIL PROTECTED]> wrote:
it doesnt rely on rowids heavily, they are only used as the best guess for ordering when selecting...they can also be disabled on a per-mapper basis, and the code that determines what the OID column is can be changed to return a primary key column instead, as it does with MySQL.
How would you want it to order elements, when you load the related elements on a many-to-many relationship ? That was the main point of trying to find an "oid", since it gives "insert order" even to an association table that doesnt have a primary key.
On Dec 31, 2005, at 6:39 PM, Jonathan Ellis wrote:
OIDs in user tables are deprecated in postgresql 8.1 (and relying on them has been discouraged for many versions now).How heavily does SA rely on rowids?Foo.selectone(foo.select(foo.c.id==1))generates sql that only depends on the PK id, butFoo.get(1)dies complaining of oid absence. Seems strange that get doesn't use a known PK.
--
Jonathan Ellis
http://spyced.blogspot.com
