Michael Bayer 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'm for returning self rather then a copy, because needing a copy in my experience thus far with SA has been the exception. What's wrong with s1 = select.copy() to explicitly get a copy.
Are you going to do the the select.where() change :-) > - 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 [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 -~----------~----~----~----~------~----~------~--~---
