On Dec 9, 2007, at 2:31 PM, Artur Siekielski wrote:
> > I'm writing DAO module for db access which must be independent of rest > of the system. I'm looking for a class which can be used as a proxy > for SQL results. Query would be good, if it would be possible to have > fully functional Query instance representing any SQL statement. But I > cannot tell users - here you have a Query object, but filtering > sometimes doesn't work! So it seems that if I want to have object- > oriented proxy for SQL results with lazy loading, I must write my own > wrapper. > OK, ive got the initial implementation for this in r3904. whatever you put into query.select_from(), thats what its going to select from. all the fun starts when you start filter()ing and join()ing. select_from() also needs to be called before you set up any joins or criterions; it will issue a warning if you do otherwise. it still needs some work, its not applied yet to count(), edge cases like group_by()/ having() dont work yet either (ticket 898 is a reminder). we will probably look into moving away from from_statement() and into select_from() since it now handles a superset of use cases. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
