Hi,
Seeing so many improvements and benefits, I might as well migrate to
0.4
Just few things I wanted to make sure before I start on that.
Inside the 0.4 branch,
1) are we still generating anonymous labels with a width of 4 char
('anon_0fda') etc?
2) there is a bug inside 0.3's strategies deferred column loader (in
maintenance branch as well), basically, when the parent's primary key
happens to be 0, deferred loading is faulty (if not attr: should have
been if not attr == None: around line 94 in strategies.py), has this
been fixed?
3) another bug in 0.3's InstrumentedAttribute system where if we set
the same value to an instrumented attribute twice, the value's parent
will be reset (to no parent)
(in resetting old's parent, we didn't check if old == value, around
line 269 in attributes.py)
4) the other thing is, property loader is ignoring it's own attribute
extensions when there is a backref, and will use the backref's
attribute extensions instead, is that meant to be the case? (same
thing in 0.4?)
Thanks in Advance
Lei
On Dec 18, 4:57 pm, Esceo <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> Thanks for the quick reply.
>
> What I am in fact doing is undefer all fields, eagerload all relations
> (and undefer the corresponding fields) for a corresponding model.
> (ended up being 9xx options altogether)
>
> And yes, I am on 0.3.11 (and probably is unable to move onto a 0.4 as
> I am relying on an old and custom version of elixir and some custom
> sqlalchemy fixes),
>
> I guess the question is whether it is possible (easy) to rip the
> benefit of those improvements by merging the 0.4 code into my current
> 0.3.11?
>
> Lei
>
> I guess the question now is,
> On Dec 18, 4:25 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 17, 2007, at 10:38 PM, Esceo wrote:
>
> > > Hi,
>
> > > I am just wondering about the traversal order of ClauseVistor, does it
> > > have to be in a set order?
>
> > > I am eagerloading lots (1000s) of relations, and query compilation
> > > take a long time, a profiling revealed that most of the time was spent
> > > in traverse.
>
> > it sounds like you are on an old version of SQLAlchemy as the compiler
> > does not use any method called "traverse" anymore. If you are on any
> > 0.4 version, our statement compilation is quite fast; as of 0.4.1
> > INSERTs and UPDATEs take around 40-50 function calls and a SELECT
> > about 120-150 (the callcount goes up with complexity obviously). Also
> > if you can clarify what "eagerloading 1000s of relations" means, since
> > i doubt you are issuing a JOIN of 1000 tables, that would be helpful.
> > If youre on an 0.3 version and switch to 0.4.1 youll see a significant
> > decrease in processing time for just about everything, and 0.4.2 is
> > going to improve an average of about 20% over 0.4.1 (available in
> > trunk if you feel like trying it).
>
> > > So, I am just wondering if the performance will bump up
> > > if we do not have to use intermediate lists (or use one less list) to
> > > maintain the traversal order.
>
> > Again assuming 0.4, there's no lists of traversal order used in
> > statement compilation, it calls each function as needed in order to
> > render each component of the select, using regular recursive
> > generation, and the order of function calls is exactly the order of
> > each component in the final string output. We profile all the time,
> > in fact on a daily basis, and we are quite fast; if you've seen those
> > infamous Robert Brewer tests, we actually beat out at least one of the
> > competitors when the tests are made fair by removing the hundreds of
> > transaction commits that only the SQLAlchemy test, but not the others,
> > is made to do. I'm debating doing some more blog posts about that.
>
> > If youre talking about the visitiors.py traversal, thats not used
> > right now in statement compilation, and the 0.4 version is also an
> > inlined, non-recursive version which is generally faster than a
> > recursive algorithm since it incurs very little method call overhead,
> > which tends to be one of the most expensive things in Python.- Hide quoted
> > text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
