On Apr 12, 2007, at 2:03 PM, jason kirtland wrote:
>
>
> The 'analysis' relation is backed by a dict-like
> collection_class keyed by the type of instance, and storing them
> in a special list type that updates the ordering attribute.
> 'analysis' isn't accessed directly by user code.
>
> # looks kinda like
> an_idea.analysis == \
> { <type 'Pro'>: [<Pro>, <Pro>], <type 'Con'>: [<Con>] }
>
> Then I'm mapping 'pros' and 'cons' properties on the Idea class
> to connect to the right partition on the 'analysis' collection.
>
> This does work, but because relation updates are happening
> outside of the InstrumentedList (i.e. not on 'analysis' directly),
> I'm losing the events that would normally be triggered. I don't
> think I can manually manage them either, as they're private
> __methods on InstrumentedList.
some ideas which im not sure if theyd work, one is to not use
"collection_class" and to go with an approach that is more like the
AssociationProxy - i.e. "pro" and "con" have special collections on
them which proxy to the utlimate "associations" colleciton, but on
top of the InstrumentedList instead of underneath it the way
collection_class does.
another option is to go with the distinct "pro" and "con" relations -
set their loading to lazy=None and manually populate them yourself,
perhaps using a MapperExtension that manually inserts instances.
this would be tricky to implement since youd have to send along a
query that includes the JOIN that you want...although you could still
have the third "analysis" relation as eager loading and viewonly=True
to get that part of it going.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [EMAIL PROTECTED]
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
-~----------~----~----~----~------~----~------~--~---
