[Glass] Conflicts when using *String and Unicode* based indexes in GemStone 3.2 and Seaside

[Dale Henrichs]

You are in a maze of twisty little messages that all look alike...

I'm afraid that in sending email back and forth with another engineer
working on the problem we got our wires crossed...

The message _sessionCacheStatAt:put: is used in Seaside while the
message _sessionStateAt:put:
is the message that overlaps with the field where  #usingUnicodeCompares is
stashed ...

It is not correct to say that Seaside interferes with  *String and Unicode*
based indexes in GemStone 3.2...

Sorry for the confusion, but I didn't notice the difference until I went to
fix the bug and noticed that were were talking about apples and oranges:)

We do have a case in the wild, where something in the image is using
_sessionStateAt:put:
... we'll just have to continue searching:)

Sorry for the noise,

Dale


On Wed, Jul 2, 2014 at 2:35 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> In 3.2 the  offsets for the System class>>_sessionStateAt:put: family of
> methods were changed at the system level (a new block of gemstone private
> session state offsets was allocated) without changing the corresponding
> offsets in the  System class>>_sessionStateAt:put: methods.
>
> Seaside uses _sessionStateAt:put: to count the number of requests handled
> among other things and it turns out that the range used by Seaside happens
> to overlap the session state used by Unicode16 class>>usingUnicodeCompares
> (which is used to indicate whether or not unicode compare mode is in effect
> or not).
>
> The #usingUnicodeCompares method  is used by the indexing subsystem to
> determine whether or not Strings are allowed to be used in Unicode indexes
> or not ...
>
> Soooo, I will be pushing out a new fix for Seaside3 ... probably 3.1.1.2
> with a fix for this bug[1] and a couple of other bugfixes[2] that were
> queued up (known bugfixes). If there is a bugfix for Seaside3.1 that you've
> been waiting on that's not on the list[2], now is a good time to bring it
> to my attention.
>
> Dale
>
> [1] https://github.com/glassdb/Seaside31/issues/29
> [2]
> https://github.com/glassdb/Seaside31/issues?milestone=1&page=1&state=open
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140702/d5cdc57f/attachment.html>