On Jun 5, 2:27 pm, 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.
This seems like a big win. There's basically no cost, and it makes
usage a lot cleaner, IMO.
>
> - 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)
Functional idioms are increasingly the standard way to design APIs.
Making copies adds a lot more flexibility to the API, and prevents
annoying errors where one piece of code accidentally mutates
annother's objects.
> * you might want to reuse the original object differently (is that
> such a common pattern ? seems weird to me..more exposition here too)
This is one I'm running into right now. I think having a functional
style object creation makes it a lot easier to write APIs that pass
around Select objects, and build them up piece by piece.
The current use case I'm running into is that I want to generate
counts of ``How many rows of the foo table that match bar criteria
were created in the last {day,week,month}'', for a bunch of different
tables and criteria. I'd like to solve this by having client code pass
in a select object with the where and from_obj populated, and having
an API method take this, generate three copies, and limit each one
with ``date <= today & date >= today-{0,7,31}''. However, this
requires me to be able to copy the partially populated select object
to make the three different where clauses
> * would be consistent with orm's Query() object which has made its
> choice on the "copy" side of things
>
> disadvantages:
> * inconsistent ? the select() function also takes a whole
> assortment of arguments which can construct the entire instance at
> once. the generative API already adds more than one way to do it.
> * performance. an application that builds queries on the fly and
> executes them will be generating many copies of a select(), most of
> which are thrown away. if the ORM uses these approaches as well,
> latency is added throughout.
I suspect the performance implications are fairly irrelevant. In most
cases, I would wager, the cost of doing the SQL queries is going to
outweigh the cost of constructing the objects to the point where you
don't really care. I don't expect applications often build and do
selects inside tight loops, so you'll only really incur the cost once
or twice per higher level action.
These are just my intuitions, (albeit based on a fair amount of
experience writing webapps with SQL/ORM backends), so anyone who could
come up with experiments to demonstrate this would be able to speak to
this issue better.
>
> for performance considerations, select() can implement both a
> generative and a non-generative API (in fact it will always have a non-
> generative API for adding modifiers anyway, just that its marked with
> underscores as semi-private). this can be specified either via
> constructor argument or by a different set of methods that are "non-
> generative". however, either of these ideas complicate the select()
> object. we might want to go with just a flag "generative=False" that
> quietly allows an application to optimize itself. or we might want to
> say, "build the select object all at once" if the overhead of
> generativeness is to be avoided.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
