[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.

Wed Oct 28 12:14:57 PDT 2015

Of course, I should have tried the query from a Seaside callback...  seems
the #seasideProcessRequestWithRetry:resultBlock:   may be related...

Will try later...

Cheers,

On Wed, Oct 28, 2015 at 3:50 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Wed, Oct 28, 2015 at 3:31 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>> ufff I could not reproduce it as a test case. However, I paste it here in
>> case you see something obvious I did wrong:
>>
>> 1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6
>>
>> 2) Via tODE in gs_3106 execute:
>>
>> | collection |
>> collection := RcIdentityBag new.
>> collection createEqualityIndexOn: 'testSelector' withLastElementClass:
>> String.
>> collection add: (TestCase new setTestSelector: 'aString').
>> collection add: (TestCase new setTestSelector: 'aUnicode7' _asUnicode7).
>> UserGlobals at: #IndexesBugReport put: collection.
>> Object new assert: (collection select: { :each | each.testSelector =
>> 'aString' }) size = 1.
>> System commitTransaction.
>>
>> 3) $GS_HOME/sys/local/bin/upgradeStone -f gs_3106 gs_329 3.2.9
>>
>> 4) Via tODE in gs_329 execute:
>>
>> Object new assert: ((UserGlobals at: #IndexesBugReport) select: { :each |
>> each.testSelector = 'aString' }) size = 1.
>>
>> But it did work... so something else may be going on.
>> ufff...
>>
>
> 5) At least with this code I can reproduce the error I got once checking
> the status of the index:
>
> | collectionsWithBadIndexes |
> IndexManager current removeAllIncompleteIndexes.
> collectionsWithBadIndexes := IndexManager current nscsWithBadIndexes.
> Transcript show: 'There are ' , collectionsWithBadIndexes size asString, '
> collections with bad indexes.'; cr.
> Transcript show: 'The following are the OOPs of such collections: '.
> collectionsWithBadIndexes do: [ :each | Transcript show: ' - ' , each
> asOop asString.  ].
> Transcript cr.
>
>
> What I cannot reproduce is the corrupt obj error from seaside...
>
>
>
>>
>>
>> On Wed, Oct 28, 2015 at 3:03 PM, Mariano Martinez Peck via Glass <
>> glass at lists.gemtalksystems.com> wrote:
>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

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