[Glass] Garbage Collection of indexes

[Mariano Martinez Peck via Glass]

On Wed, Oct 29, 2014 at 1:47 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On Wed, Oct 29, 2014 at 6:31 AM, Mariano Martinez Peck via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Hi folks,
>>
>> The GemStone Programming Guide says about indexes:
>>
>> "After creating indexes on a collection, be sure to remove these indexes
>> before dereferencing the collection. Otherwise, the index will remain and
>> prevent the collection and indexing structures from being garbage
>> collected."
>>
>> Is this still being true? Or latest GemStone do this automatically?
>>
>
> This is still true ... we are considering doing something about this in
> 3.3, but nothing firm yet...
>


ouch...ok.



>
>>
>> Also.... say I have 'collection1' which is a RcIdentityBug with the "old"
>> list of my objects. And now I have 'collection2' which is another
>> RcIdentityBad with the "new" list. Is there an automatic way to get the
>> indexes from 'collection1' and apply them to 'collection2'?
>>
>
> If you are using 3.2, the answer would be "yes, use the following":
>
>    indexSpec := collection1  indexSpec.
>    indexSpec createIndexesOn: collection2.
>
>
sweet!


> Prior to 3.2 it's not very convenient ... the closest you can get is by
> using the messages:
>
>    equalityIndexedPathsAndConstraints
>    identityIndexedPaths
>
> to get the raw information from a collection and then fabricating the
> appropriate index creation message ...
>
>
OK, thanks for the explanation.

Last question..is it ok to assume that #createIdentityIndexOn: will NOT
recreate the index if it already exist? I followed the code and I
understood that, but just wanted to be sure... so it's not a big deal if I
try to recreate an index that already exist, correct?


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141029/2efa7abc/attachment.html>