hey list -

I continue to be troubled by the slightly fragmented nature of SA's
Query object (and the cousin SelectResults).  When I work with
Hibernate, I can see that their querying interface is a little more
consistent than ours.  We have flags that are used for some things,
generative methods for others.

so id like to look into defining the next generation of query.  Id
like it to have a "quasi-generative" approach, like Hibernates.  this
means you can say:

   q = q.where(<something>).order_by(<somethingelse>)

but also, its the same as:

   q.where(<something>)
   q.order_by(<somethingelse>)

so its really the same instance (this is not how SelectResults works
at the moment).

the whole business of using SelectResults, using SelectResultsExt, all
that crap just to get a different API, id like to get rid of (i mean,
itll stay there but you wont need it).  im sorry ive made you all type
that much.

This would be a rewrite of `Query`, and we'd leave the old one around
in its usual place.  Im thinking we could put this newer `Query` on
the session under the method name `select()`.

Anyway, I put a wiki page over at http://www.sqlalchemy.org/trac/wiki/QueryV4
, with like 2 lines of code what it might look like.

I would like folks to comment on it, and add use cases, sample code,
things youd like to see.  note that Im looking mostly for the Python
API, and maybe a little bit of the method of specifying criterion, but
not really a whole new object-query layer (like building a new HQL, or
using AST-parsing, etc. i still think thats something else entirely).

Please think of something to add, particularly if you are working with
polymorphic mappings, or youve had a lot to say in past iterations
(i.e. like dmiller, dennis, etc).  I dont want to make a move on this
until something definitely cool and widely useful has been worked
out.  if we just have a vague notion of something, theres no
point...while we can prototype it, if its a side thing then not enough
people are going to use it (and therefore valid complaints wont be
heard) unless we parade this thing down the main aisle.  this query
would hopefully be the last one we write for the SA core (since we are
running out of reasonable method names on session ;) ).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to