re: I'm not particularly against the current branch, but it seems rather a small improvement over using store.execute directly. I think we can do better
The big advantage is that for the returned data we can use class expressions to get an entire class back: the filter constrains are easy to write as literal SQL; getting Storm to cast the result to objects requires using the higher level API, doesn't it?
As you can see, its a little manual at the moment, and I do like the idea of being able to define queries for more complex cases.
@therve - uses of with_ so far:
http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ devel/view/ head:/lib/ lp/bugs/ model/bugtask. py#L1925
http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ devel/view/ head:/lib/ lp/code/ model/branchmer geproposal. py#L650
http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ devel/view/ head:/lib/ lp/blueprints/ model/specifica tion.py# L636
http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ devel/view/ head:/lib/ lp/translations /model/ potmsgset. py#L449
re: I'm not particularly against the current branch, but it seems rather a small improvement over using store.execute directly. I think we can do better
The big advantage is that for the returned data we can use class expressions to get an entire class back: the filter constrains are easy to write as literal SQL; getting Storm to cast the result to objects requires using the higher level API, doesn't it?
As you can see, its a little manual at the moment, and I do like the idea of being able to define queries for more complex cases.