On Apr 16, 2007, at 8:00 PM, jason kirtland wrote:
> > 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. > you mean, youd want to create your own InstrumentedList subclass ? or how would this interface work ? also i dont entirely understand why implementing "on top" is so complicated. > 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. any kind of linking of the ORDER BY to a collection's mechanism would never be in SA's core since its a duplication of database functionality. so im not sure if those things should be linked. > A chance to error out at definition time > would be useful too. what error are we talking about ? if you can show me what kind of code youd like to write that would make it clearer what you had in mind. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
