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.

- 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)
    * you might want to reuse the original object differently (is that
such a common pattern ?  seems weird to me..more exposition here too)
    * 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.

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
-~----------~----~----~----~------~----~------~--~---

Reply via email to