Q: Complex Magma Indexed queries

[Chris Muller]

--- Brent Pinkney <brent.pinkney at aircom.co.za> wrote:

> > The way I envision this working from a user
> perspective is, the user "Reads" a
> > collection on one index (and thus obtains a
> Reader), then can "intersect:" that
> > Reader with another Reader to build yet a third
> Reader, which can be further
> > intersected with other Readers as necessary.
> 
> I think we need to concentrate on the elegance of
> the programming api: normal AND and ORs.

Well yes, of course it would be great to have that.. 
Are you serious?  Not only is that more familiar and
elegant to programmers, it doesn't waste cycles like
my approach which performs but a single intersection
for each "condition".

I like the ambition, just a bit short on clarity
about,

> The idea is that each send of #read:at:, 
> #and:from:to:, #or:at: to the reader contucts a tree
> of clauses.
> These clauses are then used to determine the
> intersection and union of oids.

particularly that last sentence.  If you are able to
do that, I am all for it.

No work needed to add an arbitrary-complex tree to the
client server protocol beyond just specifying the new
class in the #protocol..

> I have some experience from Lava with conjuntive and
> dijunctive clauses but we would need to find a way
> to express precedence or the and: or: clauses.

Don't forget the joins..  ;)

 - Chris