I'm about to post a minor update to Magma with a minor bug fix from Brent and an enhanced MaSearchStringIndex.
MaSearchStringIndex will now allow the user to specify the range of indexed characters. Four convenience methods offer the most common ranges:
#beAlpha "$A to $Z" #beAlhpaNumberic "$0 to $Z" #bePunctuated "$! to $Z" #beAscii "ascii 0 to 127"
Using the more-restricted ranges (i.e., #beAlpha) relaxes the strictness the searches while permitting more #meaningfulCharacters for the same number of bits.
This flexibility now renders MaAsciiStringIndex redundant, since you can now use a MaSearchStringIndex with #beAscii to accomplish the same thing. Therefore I would like to deprecate MaAsciiStringIndex. It will remain in the package for now, in case you have persistent instances of it, but please don't create new instances as I would like to remove it some day.
Any questions or concerns, please speak.
thanks..
Hi Chris!
I have been battling indexes for a few hours now and I am stumped. I have this really marvellously silly result that I just can't understand. I just recreated it as clean as I could:
1. Take 3.8-6665-basic. SMSqueakMap bootStrap, install Monticello, add MagmaTester repo, install MagmaServerLoader-cmm.19.
2. Install attached .st file, open test runner, run MagmaBugTests.
So what is it? Well, a MagmaCollection with a simple integer index fails to give me the THIRD object back. Kinda weird. The test adds an index, adds 100 Associations - and hey, where did the third one go? It is in the collection but the index just fails to see it.
In Gjallar it was also the THIRD Q2Txn we added to a MagmaCollection. Well, the order does not matter (you can add them in reverse, no difference) - it is the index value 3 which gives Magma the spooks :). Adding 10 to 100 works fine. But not 3.
Well, suck on that one! I tried following the code but... got disoriented.
regards, Göran
Hi!
Just tealized I should have changed the subject so that people don't miss this one. :)
regards, Göran
I have been battling indexes for a few hours now and I am stumped. I have this really marvellously silly result that I just can't understand. I just recreated it as clean as I could:
Thanks Göran. You have indeed found a bug. Magma uses a class called MaHashIndex to support its indexing. This class provides a large Integer mapping, keys to values.
Before multi-attribute query support, the only *values* in the key-value pairs would only ever be oids. The value 3 is a special value reserved in the oid map to indicate an unused entry, it is never a valid oid for any object.
But now, to support multi-attribute querys, we maintain a "reverse" index which has the *oids* as keys and index *keys* as values. So the low-level code in MaHashIndex which considers any value slot with a 3 in it as an empty slot, that is why we are seeing the silly results missing 3. In doing the queries I totally overlooked this special case!
I'll post a fix soon. Sorry for this strange problem!
Regards, Chris
Chris Muller chris@funkyobjects.org wrote:
In doing the queries I totally overlooked this special case!
I'll post a fix soon. Sorry for this strange problem!
No worries, Magma is an advanced piece of machinery and moving forward at a great pace given just one primary developer. We are bound to hit some bumps here and there.
I am glad that Gjallar is pushing it a bit. :) And we are getting close to the point where we will be banging on it seriously. I am just starting to tinker with migrating 13000 cases into Gjallar - that will surely be a great test.
And I also have work to do in the filter department - I only have a spike solution working so far - the real multi query test is in the pipe.
regards, Göran
PS. Adding and removing indexes while having other Processes with sessions (all running locally) caused other Processes to "hang" on Semaphores etc in lower levels. I will see if I can reproduce that one too - not that we intend to be adding/removing indexes often though.
I have posted new packages on the "MagmaTester" project that fixes this problem. This adds a new field to the index entries, so legacy repositories can't be opened with this. A conversion program will be easy to write if anyone needs it, but I don't want to do it unless someone really needs it.
I've just completed this at the airport and the test cases are still running through, but I don't have much more time before I have to board (and I'll be offline for a couple of days). Nevertheless, I think this will work so please feel free to start using it. I'll be back on Monday and post it to the "Magma" project then if no one finds any issues.
- Chris
magma@lists.squeakfoundation.org
-
Chris Muller -
goran＠krampe.se -
Petr Fischer