On Feb 18, 2012, at 8:05 PM, Andrey Popp wrote:
> On Sat, Feb 18, 2012 at 07:57:14PM -0500, Michael Bayer wrote:
>> I don't know that customizing instrumentationmanager is all you'd need.
>> There's lots of bookkeeping occurring with instancestate that takes time and
>> is related to state tracking and persistence. The whole need for
>> __setstate__ is due to the instancestate object. Not including it suggests
>> an entirely new system that at most would consume rows from the orm.Query and
>> route them into this alternate system.
>
> Well, I didn't want to implement entirely new system, but just to separate
> part of ORM which manages persistence from part of ORM which just map database
> columns to instance attrs.
As it is now, you can get named tuples out of Query that should be serializable
and don't use InstanceState. Rows from an execute() call also behave like
named tuples and are serializable. So I assume here you're looking for objects
that also have collections and related instances, including lazy and eager
loading of those, minus the usage of an InstanceState which you're saying is
too expensive to deserialize, or a simplified InstanceState that is somehow not
quite as expensive to deserialize, though really you'd be talking about shaving
off maybe 10-20% of function calls if it were only a simplification of
InstanceState.
It would be a major new feature add requiring architectural changes, tests, and
most importantly a clear documentation story that makes the rationale for this
alternate mode very clear and makes it totally unambiguous when this mode might
be used - else the entire project is diluted by echos of "too many ways to do
it", "too confusing", "too complicated", etc. It's complicating the internals
and API for an use case that may very well be completely obsolete in a year or
two due to Pypy and other performance techniques. The actual performance
savings may be marginal in any case.
Optimizing InstanceState while maintaining it's current behavioral contract
exactly would be a lot more straightforward, requiring no complications to
internals, API or documentation story. Methods here include experimenting
with various forms of inlining inside of __setstate__() (such as inlining the
call to setup_instance() when the default instrumentation manager is in use) as
well as experimenting with a C port. There's not much that happens inside of
__setstate__() as it is.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
