Michael Bayer wrote: > > On Feb 27, 2008, at 12:19 PM, jason kirtland wrote: > >> Michael Bayer wrote: >>> You also get a hook that receives the >>> collection_class argument in the case of a collection-based attribute >>> and you get to return your own class, in which case all the >>> collections API stuff can kick in on that side. >> This can be opened up a bit to allow custom collection event systems >> as >> well. We'd move the >> >> 'collections._prepare_instrumentation(typecallable)' >> >> out of the Attribute and into SA's default implementation of >> 'instrument_collection_class'. If custom extenders want SA >> instrumentation, they can call that themselves. The >> _prepare_instrumentation itself can become a public function, it's >> stable. >> > go for it
Ok, that's in. At the extreme end, collections can route events to anything that quacks like a CollectionAdapter. The moderate path is to make the collection's events compatible with the built-in CollectionAdapter. And of course the easy path is to just use the existing collections instrumentation toolkit, it's already plenty flexible. The sample script has an example of the extreme route, and the moderate is in test/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
