Michael wrote: > On Apr 12, 2007, at 2:03 PM, jason kirtland wrote: >> [...] >> 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.
I've got a new implementation that uses this approach and it does work- but it is even more complex. If the InstrumentedCollection refactor (#213) allows implementors to choose when to fire add/del events I think this sort of pattern can be made pretty simple. On that front, I think it would be super useful if future InstrumentedCollection classes have access to their relation() arguments- e.g. a DRY ordered collection that keys off the relation's order_by. A chance to error out at definition time would be useful too. -jek --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
