On 6/5/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> I want to wake this thread up again. can we get some arguments pro/
> con to converting select() to work in a "generative" style ?
>
> "generative" means either just the first, or both of these two things:
>
> - methods like "append_whereclause()" return a select object with
> which to call further genreative methods. this is a good thing
> because you can say select.append_whereclause().order_by().group_by()
> etc.
I don't think it's necessary to allow method chaining just because
Query does. One of our objectives is to make SQL select and ORM query
more distinct so they're not confused, especially if ORM .select() is
going to be sticking around for a while. However, I expect there will
be overwhelming pressure to add this syntax so we might as well assume
it's inevitable.
I do think .append_whereclause should be changed to .append_to_where.
A SQL statement can have only one WHERE clause; what you're actually
appending is an AND operand. .append_to_where seems to get that
across better than .append_whereclause or .append_where. The word
"clause" is superfluous because all parts of a SQL statement are
called "clauses".
> - the select object you get back is a *copy* of the object which you
> called.
> advantages include:
> * is more "Pythonic" (not sure why this is, Mike Orr said so,
> would like more exposition)
it's just bad style for a method to return self. Perl classes do it
as a pattern, while Python libraries have always avoided it. Python
methods normally return None, a new immutable object, or a calculated
value. Although as I said before, maybe it's not that big a deal for
this special case where you have to call several methods all at once
in order to get a complete SQL statement.
> * you might want to reuse the original object differently (is that
> such a common pattern ? seems weird to me..more exposition here too)
It *is* useful to prebuild part of a query, then let the caller modify
it. I went to this pattern:
def list_incidents(top_only):
q = table1.select(table1.c.is_public)
if top_only:
q.append_whereclause(table1.c.is_top)
return q
Then the caller can add more restrictions or an order_by. Because
every method modifies the query in place, I have to get a fresh select
by calling the factory again if I want to query the same table a
different way. That's not a big deal, but that is the cost of
non-generative selects. Adding a .clone() call would be convenient,
though for me it's just as easy to call my factory function again.
> * would be consistent with orm's Query() object which has made its
> choice on the "copy" side of things
Well, can we go all the way and duplicate Query's API completely?
Then there would be One Way to do it.
I suppose I should say something more about the pros/cons of .select
method chaining, but I've got a headache today so I can't think too
hard.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
