On Sep 18, 2007, at 11:42 AM, Barry Hart wrote: > Sounds great - knowing that the query will work is a big help. > > We are currently working around the absence of an > 'omit_from_results' flag, so I know that's do-able. Here are a > couple of reasons I think it's a good idea, though: > We often have functions that build a whole 'family' of queries, > filtering or sorting by different fields based on the arguments > passed. Thus, some of these queries will return tuples and some > will return objects. Since the result type returned by the query is > unpredictable, the function is not very friendly to use. why would you be calling "add_column()" in this case (besides the PG bug workaround) ?
> The consumer of the query is often framework code which we don't > control. For example, TurboGears has a paginate decorator which > automatically slices the query to return a particular subset of > results. It uses the slice operator ( q[offset:endpoint] ). Does > the slice operator eventually call the instances() function? slice calls instances() yes. the point here is that add_column() is used for a very specific thing; youd like that column in your returned results. it doesnt need to fulfill any other function beyond that (including SQL massaging required by postgres when used with distinct/order by...that massaging should happen automatically, hence the ticket). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
