Hey, Michael Bayer wrote: [snip] > The part missing for me here is that "bar", if its a MappedCollection, > is not itself a "mapped" object in the same sense that "foo" or "baz" > is. Keep in mind that a SQLAlchemy relation looks like: > > mapped class -> collection -> mapped class -> (etc.)
Yes, I think I understand this. I wrote this in my original post as the two main cases: * collection entries in a MappedCollection (or other relations). [snip] * a collection as created by a relation. [snip] I don't have my naming entirely the same way as you do yet, but I meant the individual mapped class instances (as they appear in collections) and the collection instances themselves. > If this is correct, then the assignment of __name__ and __parent__ to > "bar", which falls under the "collection", would go through different > channels than the assignment of __name__ and __parent__ to "baz", > which falls under "mapped class". In the former case, "bar" would > receive its __name__ and __parent__ upon construction through its own > collection_adapter where information about its relationship to "foo" > is readily available, and "baz" would receive its __name__ and > __parent__ when it is added to "bar" using "bar"'s own instrumented > mutator methods, where "bar" obviously knows the __name__ (the > keyfunc()) and the __parent__ is itself. Does this make sense ? Yes. Now as for the details. :) Where do I get this special collection adapter from? I'd like people to just spell out normal relations and automatically have the __parent__ and __name__ information be there in the generated collections. >> It's important to have this information no matter how the object graph >> is constructed, either by construction (as I think we covered with the >> __setitem__ change), or by retrieval from the database. > > The ORM populates collections through the @appender method, so there > is no need to instrument the "getter" methods; nothing would enter the > collection without being assigned a __parent__ and __name__. Ah, that's good to know. I was very much afraid I'd end up in a situation where I'd need to override a lot of different things everywhere - I'm looking for two precise points where I can make both use cases work the right way. > The > only restriction is that if an object is placed in a collection with > __parent__ and __name__, but is placed in *another* collection > simultaneously, then __parent__ and __name__ would be ambiguous. My > comments regarding threading and wrappers refer to the latter use > case, which may not be needed. Yes, this bit worries me. We can use wrappers in the form of location proxies; does the @appender method allow one to do the wrapping in the location proxy? Or is this object actually supposed to be only there one and is in two collections at once (preserving the identity relationship)? So how do I override this appender method? Is this the monkey-patching approach you describe in your second code sketch? Regards, Martijn --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
