On May 1, 2008, at 5:24 AM, Kyle Schaffrick wrote:
There are two versions of its implementation, one based on the other.
The original one tries to find mapper properties on the instances or
column entities that match the expressions given. The upside is that
it
doesn't alter the generated SQL. The downside is that it's kind of
fragile and can silently break in wierd ways, such as if the mapped
class sets up it's own property accessors that mutate the value in a
way
that might change the comparison behavior and resultant ordering. It
also gives up and raises an exception if it can't find said properties
or columns (for reasons which may or may not constitute a user error).
The second version eschews this magic for a more robust method, which
involves adding column entities to the query that are used find the
merge ordering and are then stripped from the results before the query
returns them. Upside is that AFAIK it works with any expression that
can
be order_by()'ed, downside is obviously that it changes the generated
SQL. It does, however, check to see if the user already explicitly
added
a matching column entity to the query, and uses that instead of
duplicating it.
at first the second method seemed a little hacky to me, but now that i
think about it, we're in the sharded query so removing the extra
entity is not a big deal.The first method is probably not as
fragile as you think, as if someone uses MyClass.someproperty in a SQL
context, it is meant to have real meaning in that context, and in all
cases it should be an InstrumentedAttribute. Even an end-user-
defined attribute will use comparable_property() and will ensure that
it generates reasonable SQL. But adding the clause explicitly to the
SQL is a good idea here regardless since its analgous to ORDER BY,
which also adds the clause to the SQL (just in a different way).
There are some rough edges, particularly reduce_ordering_expression(),
that I'm fairly sure are not done The Right Way, and there are
probably
some latent bugs, so I'd be interested in any feedback.
I haven't looked at the code yetbut you should also take a look at
the Query implementation in user_defined_state (which is going to be
0.5 RSN) to see if you need to make any modifications over there. in
particular the implementation style of a generative method is
different and you might want to use that newer system.
It might be worth it for us just to totally consider this feature
within 0.5 since 0.4 is quickly becoming feature-frozen.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
