well there would have to be some flag to not register a "dependency" between classes A and B (or rows C and D). the "post_update" flag actually does this, but comes with the extra "update this value later" behavior.
with the dependency removed, the topological sort wont need to fulfill that part of the sort and wont raise the circular sorting issue. however, with constraints removed, doesnt mean we can do operations in just any old order. namely, if a row in table B references table A, and A is to be inserted, if A does not yet have a primary key value generated we would still have to insert A first, since the generation of primary keys is necessarily bundled with INSERT operations, which of course is because not every database supports sequences and we have to rely on cursor.lastrowid and stuff like that. this might be something youre better off doing by not even establishing the post_updated relation() at all (or establishing the relation as "viewonly"), and just implementing yourself a series of before_insert() MapperExtensions that populate the "post_updated" value and possibly also pre-generates the primary key column ahead of when its normally generated....since the model you want depends on the primary key value of the child object being generated before the parent object is inserted, and thats not normal ORM behavior. remember that you can set all the PK/FK attributes you want on your instances, either before flush() or within before_insert() operations, and SA will use those values when inserting the rows for the instance if they are present. On Feb 23, 2007, at 2:03 PM, Luke Stebbing wrote: > > PG and Oracle allow you to defer foreign key constraints (Oracle > apparently lets you defer *all* constraints, mmm), and MySQL and > SQLite (of course) don't. I'm not sure about other databases. The SQL > keyword in question is DEFERRABLE. > > References: > > http://www.postgresql.org/docs/8.2/interactive/sql-createtable.html > http://www.postgresql.org/docs/8.2/interactive/sql-set- > constraints.html > > http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14231/ > general.htm#i1006803 > http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14200/ > clauses002.htm#sthref2933 > http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14200/ > statements_10003.htm#i2066960 > > On Feb 22, 3:20 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: >> ive heard of foreign key constraints that dont take effect until the >> tranasction actually commits, but I have never actually seen this in >> practice. which databases support this feature ? i didnt think it >> was so common (though not surprised PG supports it). >> >> On Feb 22, 2007, at 1:15 PM, Luke Stebbing wrote: >> >> >> >>> Are there any plans to handle circular dependencies by using >>> deferrable foreign key constraints when available? >> >>> In my case, I had made the foreign key constraints deferred, but >>> SQLAlchemy didn't pick up on that when I reflected the database >>> metadata. I eliminated the circular dependency by using >>> post_update=True, but that meant dropping a NOT NULL constraint >>> since >>> postgres can't defer those (sigh). > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
