[PonyORM-list] Algebra of sets

[Alexander Kozlovsky]

>
> As you can see, the first code block uses the same parameter name in
> generator and lambda and works fine, while the second one uses different
> names and fails with exception, being fine from the point of lambda syntax
> and semantic view. This inconvinience leads to difficulties in code
> isolation (lambda writer should know name of the generator parameter, which
> might be hidden in other subsystem written by other team).


Yeah, this is how things currently work. It is not possible to just accept
arbitrary parameter name, because generator can consist of several
for-loops and have several variables. For example:

    q = select(g for g in Group if g.dept.number == 44
                 for s in g.students if s.gpa > 3)
    q.filter(lambda s: s.name.startswith('J'))
    q.filter(lambda g: g.number == 101)

It will be non-intuitive if parameter name can be arbitrary when query has
only one for-loop, but becomes non-arbitrary with multiple for-loops.

So yes, filter API requires knowledge of generator variable names, and it
may restrict independence of different subsystems. But probably this is not
critical if system-wide conventions can be made. For example, "all queries
which returns User should use 'u' as a variable name", etc.

> Is this inconvinience particularly one which you meant, or something
other?

Don't remember I said something like that, I spoke purely about performance
of INTERSECT / UNION in SQL

As for the intersection, union and subtraction, these functions might be
> constructed using logic combinations of filter expressions in involved
> queries instead of using special SQL syntax to implement them IMHO (and
> that is really what I meant before).


 The first two cases might be implemented easy using existent .filter()
> functionality.


Although it is doable, I suspect it may be not as easy as it seems, if the
goal is to combine expression trees with different variable names. Anyway,
thanks for the suggestion, I'll think about it later.

Best regards,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ponyorm-list/attachments/20131024/4857df94/attachment.html>