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