Hey Michael,
Thanks for the helpful answer.
Michael Bayer wrote:
[snip]
> (after I've reread the above
> two paragraphs many times it seems like the idea is that the target
> object doesn't know anything about the name of the relation in which
> its collected).
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.
> I'm not as fluent with the collection API (since Jason wrote it) but
> it turns out its pretty easy to get at the "parent" object and the
> relation which its mapped through a collection directly, since
> collections always have an "adapter" present which maintains this
> relationship.
Thanks, that's interesting to know. It turns out though that the adapter
considers the owner state of bar[key] to be foo, so we can't use that
as a parent. That actually simplifies things and it turns out that in my
modified version of _receive the adapter doesn't appear to be necessary.
Still, good to have some idea about how to use them. I have this now:
def _receive(self, item):
item.__name__ = unicode(self.keyfunc(item))
item.__parent__ = self
> This would still involve overriding the behavior of all the mutator
> methods on collections. I'm not sure why you'd want to override
> "retrieve" methods as well, are we able to assign __name__ and
> __parent__ to elements as they are added, or do these change depending
> on where the item is accessed from ? (and if the latter, is it
> wrapped in a container of some kind, or are we guaranteeing single-
> threaded access?)
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. So yes, the
__parent__ information does indeed change depending on where the item is
accessed.
I take it however that there might be a problem with threaded access.
It's certainly possible for the same object to be accessed in multiple
threads, but each thread has its own session associated with it using
scoped sessions. I take it that isn't enough?
We do have support for a proxy object that can add these attributes
without modifying the object itself. That wouldn't handle the
__setitem__ case probably though, but it could be used to make sure an
object is properly wrapped when accessing, even though the same object
may be retrieved with multiple parents. Hm, I see this conflicting with
SQLAlchemy's ORM, where it's certainly possible for the same object to
appear multiple times in the object graph.
Thanks for the proof of concept. With my modifications it makes my tests
pass, but that's a sign the tests are insufficient. :)
Given the complexities involved, I need to rethink whether this whole
approach is the right one. If it could be made to work it'd make URL
construction work out of the box, but there are other ways...
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
-~----------~----~----~----~------~----~------~--~---
