On Aug 18, 2008, at 11:42 AM, Martijn Faassen wrote:
> The idea is that if the object graph says:
>
> foo.bar.baz
>
> that'll be:
>
> bar.__name__ == 'bar'
> bar.__parent__ is foo
> baz.__name__ == 'baz'
> baz.__parent__ is bar
>
> In this case:
>
> foo.bar[key]
>
> it'll be:
>
> bar[key].__parent__ is foo.bar
> bar[key].__name__ == key
>
> where 'bar' is a collection.
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.)
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 ?
>
> 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__. 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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
