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
-~--~~~~--~~--~--~---