I've only ever wanted to copy the select() item, usually as a component of a generic "query builder" like thing. But maybe things like .alias() and .label() could be made into generative versions that might make it easier to reassign names on the fly. As far as the individual clause elements themselves, I don't see much of a use case.
On 5/9/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > > On May 9, 2007, at 4:08 PM, Rick Morrison wrote: > > > Hey Mike, > > > > I've really gotten to like the generative style of query building > > that the ORM layer uses, and I find myself developing a number of > > patterns that use that style to > > good advantage. > > > > Today I found myself struggling with a query in the low-level SQL- > > API layer that the generative approach would make really easy -- is > > there a way to get the same kind of generative effect in the lower > > layers? > > > > Right now I'm kind of hacking something that uses copy.copy() on > > the select(), and that surprisingly seems to work, but makes me > > think there must be a better way. > > > > > > yeah i really should have just imitated Hibernate more closely when i > started this thing. > > theres no technical reason generativeness couldnt be applied to > ClauseElements except for potential API messiness. we do have > methods on select() that modify it, such as append_whereclause(), > order_by(), and such...if they just returned "self", then you could > act more "generatively" with it, i.e. select(...).append_whereclause > ().order_by()..etc. > > then again, true "generativeness" would have simpler method names > like just "where()", "from()", etc. and I suppose those arent a big > deal to add. like with Query, im not sure what the advantage is to > the select() being actually "copied" though i guess thats the "safer" > approach (but notably is not how Hibernate's Criterion object works; > you get the same one back each time). so the "do we actually copy" > is a big decision to make, and unfortunately Query has made its > decision on the "yes" side so i think we might have to lean that way > for consistency. > > on a related note we have a ticket in place to allow "select()" to be > "copyable", which is not a big deal but i want there to be some nice > tests set up for that since a select has a lot of elements that need > to be faithfully copied over. > > we are close to a 0.4 so perhaps that would be a good time for some > slight API change on select(). > > also it seems like select() is really the only construct that really > could use "generativeness"...other constructs like joins, aliases, > etc., already have methods to create new objects from them, but as > far as mutating operations it seems select() is the only real > candidate (would you want generativeness on other constructs, like > CASE, boolean operators, etc?) > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
