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