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.
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?Barry
----- Original Message ----
From: Michael Bayer <[EMAIL PROTECTED]>
To: sqlalchemy@googlegroups.com
Sent: Monday, September 17, 2007 5:41:38 PM
Subject: [sqlalchemy] Re: Error combining DISTINCT and ORDER BY in an ORM query
on PostgreSQL
On Sep 17, 2007, at 9:53 AM, Barry Hart wrote:
I've started using add_column() as needed to work around this. Our application
tends to have a single, fairly generic filter_sort function for each class.
Some use cases of this function require add_column() and some don't. From the
caller's perspective, the filter_sort() function is poorly encapsulated because
sometimes it sometimes returns objects and sometimes tuples.
It'd be very helpful if the add_column() function took an optional parameter
'omit_from_results' telling whether the column should be included in the
results, then our filter_sort() functions could always return objects.
alternatively, ORM can ensure columns are present in the columns clause when
used with DISTINCT/ORDER BY. we're trying not to complicate the public API
with arbitrary switches and flags. ticket #786 added, as an interim, your
filter_sort() can either detect the tuples, or if its just returning the Query
object itself, can perhaps patch the individual Query object to not return the
tuples (i.e. wrap its instances() method with a de-tupleizer).
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
