Q: Complex Magma Indexed queries
Brent Pinkney
brent.pinkney at aircom.co.za
Tue Dec 20 08:40:40 UTC 2005
> 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
More information about the Magma
mailing list