Michael Bayer wrote: > youre basically saying that Hibernate supports mutation operations > upon instrumented collections, without it needing to load the full > state of those collections from the database. how would this > support the add() method on Set (need to replace an existing item > which may not be loaded) ? __contains__() ? __setitem__() (recall > we might need to maintain ordering) ? i dont really see how that > would work. append() seems to be the only method where we can even > get away with it, and im not completely sure that is without issues.
I don't think that's what I said; at least it's not what I meant to say. What I was suggesting was nothing like how Hibernate does it because Hibernate does not automatically add objects to association collections. The suggestion I made was an attempt to keep that automatic behavior of the backref feature while improving its lazy loading behavior. You're saying it's too complicated and I'm fine with that. Take a look at this example in the Hibernate documentation: http://www.hibernate.org/hib_docs/v3/reference/en/html/example-parentchild.html#example-parentchild-bidir Hibernate does not automatically add child to parent.children when child.parent is set. Here is the code snippet from the example that illustrates that (warning: this is Java code): Parent p = (Parent) session.load(Parent.class, pid); Child c = new Child(); c.setParent(p); p.getChildren().add(c); session.save(c); session.flush(); Notice how it's necessary to do both c.parent = p and p.children.append(c). They later combine these into a single statement by adding an addChild() method to the parent object, but that's totally outside of Hibernate. The key here is that the child is managing the association since they set inverse=True on the parent.children mapping. The p.children.append(c) is only there to keep the p.children collection up-to-date in memory; it does not cause any SQL to be executed. In my case that collection does not need to be kept up-to-date so that step can be omitted. It may be useful to add an inverse=True keyword arg to SA's relation() function, which would tell SA not to update the relationship based on items added to or deleted from that side of the association. That would be closer to how Hibernate does it. > > right now, the collection implementation corresponding to a relation > () can be anything; a list, dict, Set, user-defined object, etc., > it is only created after the entire collection has been loaded, so > there is no ambiguity over its contents and no surprises or > assumptions with any operations upon those collections. to do away > with that means we have to greatly complicate the instrumentation of > collection classes, add built-in latency to at least the append() > method if not many others, and make lots of assumptions about which > methods do trigger a load and which ones do not... all for what is > essentially just an optimization. Now that I've researched it more I do agree that it's probably not worth the extra complexity to enhance the backref feature in the way I was suggesting. It's a good idea to keep it as simple as possible. If we were to make it more like Hibernate we would take out the feature of backref that adds the associated child to parent.children. However, that might break too much existing code... Like I said, I've found a workaround so it's not a big deal. > SA greatly favors stability and > simplicity over optimizations...things are complicated enough and I > already have to spend several hours every day just getting what we > have to be stable. Wow, don't burn yourself out. I wasn't demanding that you implement this feature, I just wanted to discuss it on the list. I even started to work on a patch last night but it got too late and I had to go to bed. Seriously, make sure you don't burn yourself out. You've been an amazing source of help for everyone getting started with SA, and it would be a shame if you couldn't keep working on it. ~ Daniel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
