[Glass] Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Wed Oct 28 11:03:34 PDT 2015


On Wed, Oct 28, 2015 at 2:56 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 10/28/2015 10:48 AM, Mariano Martinez Peck wrote:
>
>
>
> On Wed, Oct 28, 2015 at 2:32 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> I guess the exact unicode error message would be a starting point ...
>>
>>
> Hi Dale,
>
> Ok, I opened a new thread, as you asked.
> OK I will try to recover it (I must recover from backup so give me a few).
>
>
>
>> This whole thread started because we had a bug that would throw a
>> corruptObj message when invalid unicode was fed to a unicode primitive ...
>> that bug was fixed in 3.2.2 or so ...
>>
>> So this corruptObj message is occuring for a different reason altogether
>> ...
>>
>> In general you should not have to rebuild indexes across upgrade
>> boundaries (unless we document that you have to) ....
>>
>> While it is good to know that a rebuild of indexes fixed you problem,. I
>> am still interested in understanding what caused the error in the first
>> place, since it may actually be another bug ...
>>
>>
> Dale, a few things:
>
> 1) The original stack / code that triggered the real error was NEVER show
> anywhere. From the "button" I clicked in my app, which caused the problem,
> I can tell you 99% that the error ocurred when I performed a query using
> the special syntax ( {   }  ) for accessing an index of a collection.
> The fact of not seeing the REAL stack, WAS a problem.
>
> and that is another reason for me to get to the bottom of this ...
>

Yes, this was a bit of a pain not being able to get the original error.


>
>
> 2) From what I understand, I DID have to rebuild my indexes because in the
> documentation it said that instances of Unicode7 cannot coexist together
> with isntance of String in the same index. Let's say I have an index on a
> instVar called 'tickerSymbol' of class XXX. I had a RcIdentitySet with
> instances of XXX in which some instances have a String instance in
> 'tickerSymbol' and others had a Unicode7 as instance. (why?  no clue...).
> In the documentation I read this was not possible anymore and if this were
> the case I would need to create a Unicode-kind of index. And that's what I
> did and what it worked.
>
> okay so that information was true ... and we did document it ... so we are
> down to trying to understand where the  error that is causing the
> corruptObj error on commit
>
>
>
Indeed.


> I think the bug (if it IS a bug..and if it is reproducible) should be very
> easy to reproduce with tODE and gsDevKit
>
> 1) create 3.1.0.6 stone called gs_3106
> 2) Create dummy ClassWithIndex with instVar 'instVarWithIndex'.
> 3) Create a equality index over instVar 'instVarWithIndex' with path
> element class String (old API since we are in 3.1.0.6)
> 4) Store in #myUserGlobals a RcIdentityBag with 2 instances of
> ClassWithIndex, one with a String in 'instVarWithIndex' and one with a
> Unicode7 instance.
> 5) Use `upgradeStone` (forcing a target 3.2.9 stone called gs_329) to
> upgrade from gs_3106 to gs_329
> 6) Make a #select: { } using 'instVarWithIndex' in the RcIdentityBag
> stored in the userglobals.
>
>
> This is enough for me to take a crack at reproducing the problem ... these
> are the details that I needed ... thanks ...
>
> I've got a full plate right now, so I will try to get this reproduced and
> then perhaps defer on characterizing as the fix will likely not be a simple
> Smalltalk-based solution ... nonetheless I want to get this one under the
> microscope ... thanks!
>

ok, no problem. I will see if I can reproduce it too.


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


More information about the Glass mailing list