On 3/24/06, Michael Bayer <[EMAIL PROTECTED]> wrote: [snip] > 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). Why don't the bi-directional relationships handle that?
> > 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. > I tried adding these two lines after 'objectstore.clear()': objectstore.expire(child1) objectstore.refresh(child3) And none of them made the test pass, I must be failling to understand what are these methods supposed to do. > 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. I don't understand what you mean with "I shouldn't expect anything from child3". If clear means that fields will be reloaded why isn't the 'childs' property reloaded after a 'clear', IMHO it would _expect_ it to be reloaded after a 'commit'. Also child3 is still a perfectly valid object since the only thing that happened was its parent was removed. > > 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. It has a clear on line 47 and a comment asking why I need to call it explicitly. If I comment it out the test on line 53 and 54 fail, which means that if I don't call it the references on *new* objects will not be updated and therefore 'new_root is root' and 'new_child3 is child3'. > 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. What kind of things can be lying around? That's what I don't get. From my tests it looks like it's something regarding to marking the objects that referenciate a certain OID as 'dirty' which will in turn make the mapper create new instances of the mapped class (more on this latter). > 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. The big problem here is, how do I propagate a delete on cached properties, like 'childs'? How do I mark them as 'dirty' in order for the 'objectstore.commit()' or 'objectstore.clear()' makes the next call to this field to refresh the value from the database? Making the use refresh all the references to the object seems a little strange since that there are cases where those objects are not aware that such action (an object removal) has happened and it's specially ackward that I need to refresh my reference to a _new_ object, instead of updating the content of the old one. In my idea there should be only one copy of each mapped object. Every 'mapper.get(some_id)' should return *always* the same object. -- Tiago Cogumbreiro <[EMAIL PROTECTED]> http://s1x.homelinux.net/ ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
