[PonyORM-list] Separating projection and filter in Query?

[Tomislav Tustonic]

Alexander Kozlovsky wrote:
> Hi, Tomislav!
Hello!
Thanks for the quick response.
>
> In your first example
>
>     q = select(p.name <http://p.name> for p in Person)
>     q = q.filter(lambda p: p.age > 30)
>
> The filter didn't work, because the argument "p" used in lambda refers to the 
> entire result of the first query, that
Yes, I know. I just put it as an example of what I'm trying to accomplish.
> To fix this, we should refer to the iterator names of the original select. It 
> is possible if we write lambda without arguments as in the following example:
>
>     q = select(p.name <http://p.name> for p in Person)
>     q = q.filter(lambda: p.age > 30)
>
> When lambda doesn't receive any arguments, it refers to the names used in the 
> original select, so it is possible to refine query with any filtering criteria.
This is great! I didn't know this was possible! You should put more examples 
and/or documentation describing these finer features.
>
> As per the second example:
>
>     q2 = select(p.name <http://p.name> for p in q1)
>
> Pony doesn't support such queries right now, but we plan to add them later.
That would be excellent.
> We can add a way to specify projection, but at first we should understand what 
> is the right API to do such projection. There are two options:
>
> 1) A programmer can specify the desired attributes when they write a query. In 
> this case a query returns entity objects, but internally they contains 
> specified attributes only. Other attributes behave as if they are lazy - their 
> values will be loaded by a separate query if you'll try to access them.
>
> 2) Another option would be to have the map() query method which can transform 
> query result:
>
> In this case, you don't receive partially-loaded object from the query, but 
> instead you get attribute values. This way only the specified attributes will 
> be loaded from the database.
>
> What do you think, which API option solves your task better?
As I said, I'm just exploring the possibilities, so I don't have a concrete task 
at the moment. The thing about dropdown lists and datagrids was an example (but, 
based on some previous projects).
Personally, I'd prefer API option 2. The 1. option seems a bit too magical :) 
But I don't see a difference between the result of the API 2 and the planned 
feature:
q2 = select(p.name <http://p.name> for p in q1)
As I see it, both of them would eventually give me a tuple with the selected 
attribute values, with (perhaps) the additional possibility of further filtering 
and/or projecting q2 :)
However, being a long time C# and Linq developer, the planned feature seems the 
most 'natural' to me, so this would be fine when it comes out.
So, in a nutshell:
1. planned feature
2. API 2
3. API 1

Thanks,
Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ponyorm-list/attachments/20140814/f1cfa75a/attachment.html>