Hi, Magma People
The question is: is there a way to force an index to update its keys? or Suposing an index is not properly updated or is not updated at all, can I force this updating?
You would demand: why do you need this? Perhaps something is wrong in your objects, so the index is not updated.
No, the problem is that this index doen't match with an instance variable of the objects in the collection. It's a key generated when other condiciones changes, produced by a message, not an instance vairable. I suposse that magma doesn't update the indec because there's no changes in variables. Am I wright?
But you would insist: why do you need this? A "calculated" index? Why don't you use a variable?
I have this situation: there are several methods for testing the objects, that answer a boolean. I need to filter the collections regarding wich objects answer true, and wich others answer false. I need something like a filter, but I didn't find it. The way I found to solve this problem is to generate a single key that uses the boolens as they were bits, so with an integer index, I cant retrieve the objetos with several filterings. But the index is not updated! The only way is to remove and recreate it.
Thanks in advance.
Norberto
The question is: is there a way to force an index to update its keys? or
Norberto, please check the Magma documentation page, it tells you how to update index values.
Suposing an index is not properly updated or is not updated at all, can I force this updating?
Not easily. If you didn't correctly notify Magma of index key changes and the index is now out of date, the best thing to do would be to delete and re-add the object so it will be indexed at the correct keys.
You would demand: why do you need this? Perhaps something is wrong in your objects, so the index is not updated.
Uhhh... No, I would demand nothing of the sort.
No, the problem is that this index doen't match with an instance variable of the objects in the collection. It's a key generated when other condiciones changes, produced by a message, not an instance vairable. I suposse that magma doesn't update the indec because there's no changes in variables. Am I wright?
No, that is wrong. You may be thinking of GemStone, which indexes the values of instance-variables. Magma indexes the return value of the method denoted by the indexed attribute. Changes in variables have no bearing on updates, you have to send #noteOldKeysFor:.
But you would insist: why do you need this? A "calculated" index? Why don't you use a variable?
I have this situation: there are several methods for testing the objects, that answer a boolean. I need to filter the collections regarding wich objects answer true, and wich others answer false. I need something like a filter, but I didn't find it. The way I found to solve this problem is to generate a single key that uses the boolens as they were bits, so with an integer index, I cant retrieve the objetos with several filterings. But the index is not updated! The only way is to remove and recreate it.
You never want to use an index that can only have two values. Instead, you would simply have two collections, one for the true's, the other for the falses..
- Chris
No, that is wrong. You may be thinking of GemStone, which indexes the values of instance-variables. Magma indexes the return value of the method denoted by the indexed attribute. Changes in variables have no bearing on updates, you have to send #noteOldKeysFor:.
Perhaps I didn't express the idea correctly. I meant Magma updates automacally indexes with match an instance variable. Indexes wich may change by a value answered by a method must be updated manually (using #noteOldKeysFor:). I'm quite sure an index was not updated for thise reason, while the others were.
You never want to use an index that can only have two values. Instead, you would simply have two collections, one for the true's, the other for the falses..
I don't get your point. Do you mean I might divide the collection (once) so half of the objects are in "true state" and the others in "false state"? That's not possible, since I have many state conditions for one single object. Even if I had only one state, it's not very confortable to divide things that are thougth as bound. I'd have to consider that this particulars objects are divided in two, while others are not. Or do you mean, I have to persist the objects in different collections, each pair of collection correspoding to a true-false condition.? I think this is not very nice. And the problem of the singularity of one kind of objects persists.
Regards Norberto
I don't get your point. Do you mean I might divide the collection (once) so half of the objects are in "true state" and the others in "false state"? That's not possible, since I have many state conditions for one single object. Even if I had only one state, it's not very confortable to divide things that are thougth as bound. I'd have to consider that this particulars objects are divided in two, while others are not. Or do you mean,have to persist the objects in different collections, each pair of collection correspoding to a true-false condition.? I think this is not very nice. And the problem of the singularity of one kind of objects persists.
Magma's indices are based on integer hashes: all objects who index attribute has the same value will have the same hash value. At this point, finding the object in the index becomes a linear search.
By definition boolean object hash to on of two values, 0 or 1
I managed to minimise the impact of this restriction by hashing false to the range 0 - 32767 and true to 32768-65535. Finding object was no quicker, but inserting object was much, much quicker.
Brent
magma@lists.squeakfoundation.org