Q: Complex Magma Indexed queries

[Brent Pinkney]

> 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.

Something like the 'brush' model used by Seaside 2.6

	| reader |
	reader :=  myCollection reader.		"answer a MaCollectionReader"
	reader 
		read: #familyName at: 'Smith';
		and: #dateOfBirth from: 1972 asYear to: 1975 asYear;
		or: #gender at: 'female'.

	reader do: [ :p | p doSomething ].

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.

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.

But this kind of interface is my general idea.

> At the MaHashIndex level, calculating an intersection is very easy to implement
> using the "Bit Vectors" approach described at:
> 
>   http://www2.toki.or.id/book/AlgDesignManual/BOOK/BOOK3/NODE133.HTM

Really light reading.

> 2) Creating a consistent Reader "view" of this intersection
> 
> The easiest way to tackle this is to use the existing Reader logic that's
> already built-in; therefore we must have the "intersected MaHashIndex" (or
> equivalent) as its back-end.  From my view, this is the best and only way to
> leverage all the code that's there, which was painstakingly implemented to
> correctness.

Agreed, see above.

> The challenge is howp do we know the user is done with the temporary,
> intersected MaHashIndex?  The only answer I can think of at the moment is to
> require them to #recycle it or something (yuck).

No idea yet.

> 3) Keeping it up to date
> Don't even want to worry about this right now unless we can solve 1 & 2...

No idea.

> > Comments welcomed
> 
> Consider also that we have the ability to write a custom index that indexes on
> multiple attributes simultaneously.  For example, for each person, you could
> insert two hash values into one index, one for the familyName and one for the
> dateOfBirth.

Agreed, such synthesised hashes are a workaround.

Cheers

Brent