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 yet....but 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 -~----------~----~----~----~------~----~------~--~---
