Michael Bayer wrote:
Piecing together a select() construct and compiling to a string is a
relatively inexpensive operation. The vast majority of time in Query is
spent about 1/3rd-half on the database side and the rest in fetching rows
and instantiating/populating objects.
Fair enough.
has to traverse mapped classes to generate. But its a fraction of what
it takes to fetch rows, and in that area we'd ultimately like to
reimplement that part in C.
I hope the use of the C part always remains thoroughly optional, since C
extensions cause a world of pain in a lot of situations...
<snip>
All of that said we are always welcome to patches and new core developer
candidates since a really well designed implementation of such is
certainly something we can look for - particularly if it could be a
"pluggable" option that people don't have to use, which would allow it to
become mature on its own as its used by people without impacting the
current userbase.
Thanks for the thorough coverage of this, it's verymuch appreciated. Now
that I understand more about what's going on during the query process,
I'm in total agreement with you :-)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
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.
