hmm, actualy, in such select.append_whereclause().order_by().group_by().whatever1 ().whatever2()... What is the point of anything except the very first funccall to be generative? the direct results are thrown away, and the copies are used - whyfore?
(i guess this applies to query() as well...) isn't it better to just have s2 = select1.clone().order_by().group_by().whatever1().whatever2() so the original select1 is left intact, and s2 is a development of a clone of s1. ------ before figuring the above, i wrote this below, but now it seems less important: for me the main advantage is that it will match query's general behaviour / footprint - query() being ORM's way for doing .select's. as long as i have both generative/copying and non-generative (inplace-modify) alternatives, it seems ok. whether the default behaivour to be the generative or the non-generative - this argument can last forever, so just choose one (the easier/less surprising), and provide 2 methods for those "i hate to write long keyword-args". same as for ORM's query(). u can even have the default choice as class-variable, But afaik u almost have no such class-level defaults, so your choice. heh, u can have some current_generativeness flag which can be set or unset by a func. hence: s1 = select.where(x).order_by(y) s2 = s1.set_generative().group_by(z).whatever() will all the order_by() etc be generative only, or they will have that choice flag too? or will follow the whatever choice has already been made? svil > 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 [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 -~----------~----~----~----~------~----~------~--~---
