Tiago Cogumbreiro wrote: > Meanwhile I'm having a bit of a problem handling deleted elements. > I've picked up your 'backref_tree' example and added some testcases to > explain my problem: after deleting the elements of a relation the > other side - the attribute - of the relation is not refreshed after a > objectstore.commit() followed by a objectstore.clear(). Is this the > expected behaviour, if it is can you please explain me why? The > problem is that this will raise inconsistencies and obligate all the > reference objects to be refreshed.
this is correct, SQLAlchemy's primary job is to generate SQL statements. it has minimal attribute management capabilities in order to track changes for the purposes of committing the changes on a graph of objects, as well as a "backreference" function that will keep bi-directional relationships evened up, but otherwise it isnt going to automatically manipulate object structures in response to SQL operations. So your "father" on "child3" object hanging around is because you havent detached it (or removed "child3" from "child1's" list). There is a method called "refresh" as well as another called "expire" that can be used on objects to refresh them, or mark for refreshing. either of those methods will reload or mark all the attributes on "child3" to be reloaded. as it turns out those methods, which have only been around for a couple of weeks, had a little glitch in them with this particular example, so I just committed a fix for that rev 1193. but also, your program shouldnt expect anything from child3 at all because you cleared the objectstore beforehand; generally clearing the objectstore means youre starting fresh and will re-load everything from the database. > > Another question why does the 'clear' method must be called after a > 'commit'? If I'm committing my change isn't it expected that all the > remaining queries be flushed into the server? im not sure why you would think clear() must be called after commit(). the original example program that you are working with does not have a "clear()" in it. clear() it is useful in examples and test cases as something to do before you load data from the database, to guarantee that all mapper queries will return newly loaded objects as opposed to objects still lying around in the identity map. like the docs mention, it is also pretty important for web applications at the beginning of a request so that nothing from the last request is left lying around. > On a side note, the deleting objects part is really missing on the > docs. There are no example on how deleting objects affect the > remaining "ecosystem", hence my confusion. OK fair enough, but its due to the fact that deleting an object has pretty much no effect on the remaining "ecosystem", it just sends a DELETE instruction to the database, as well as assuming you wont do much with that object anymore since it gets removed from the current uow session. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
