On Feb 1, 2014, at 7:25 AM, lars van gemerden <[email protected]> wrote:
> Thanks, this helps some to narrow it down. > > Trying to zoom in: > > - why would sqla try to UPDATE (instead of INSERT) a row in the database, > when the row/object was never committed before? UPDATE is emitted for an object that is in the “persistent” state, that is, has an identity key. you can view this key via inspect(myobject).key as well as inspect(myobject).has_identity. > - when you flush an object to the database and then close the session that > flushed (no commit), what happens to the flushed data? if you close the session, the session doesn’t commit the transaction, it releases the connection to the connection pool, and assuming the pool is used with its default settings a rollback() is emitted on that connection. > - if an object is in a session and it has_identity, why would accessing > obj.id (id is the primary key) fail (see above)? i really don’t know, the code snippets you’re sending are long yet are not complete and therefore not runnable, and omit details that may be important. if you want me to step through exactly what’s happening you need to give me a complete and self contained (and succinct!) test case. > - Is there (in principle) a problem with: > + having an object of a mapped class which was never committed (but > maybe was added to a session and flushed, after which the session was closed) > + setting an attribute of that object with another object that was > queried from the database > + committing the first object to the database? yeah, if that first object was flushed, then its session would have considered it to be persistent, yet if the session were not committed but the now detached object still used, it essentially represents a bogus row.
signature.asc
Description: Message signed with OpenPGP using GPGMail
