Bug 44685

Bug: 44685

Impact:

Informational

Product:

GemStone/S 64 Bit

Versions:

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.1, 3.0

Platform:

Fixed In:

postConv only automatically converts sortBlocks that are SimpleBlocks

Blocks in  2.x applications may be simple or complex.  Complex blocks are created when the block code includes references to the block's context, or in the case of certain syntactical features.  For such blocks, automatic recompliation may not be safe. postConv attempts to recompile the sort blocks of persistent SortedCollections in the application, but if any of these blocks are complex, they will not be converted, and will be reported as errors from portConv.

Note that you may have many instances of SortedCollection that reference the same sortBlock, such as when the sortBlock is in a method.

Workaround

You will need to manually update the sortBlocks of persistent SortedCollections.  For instances returned in the  FailedSortedCollections bitmap, perform code of the form:
    aSortedCollection sortBlock: (recompiled sortBlock).

To determine the cause of specific sortBlock recompile failures, examine the source code for the SortedCollection's sortBlock. If there are reference to method context (such as self, or a variable), this may require defining a special method to provide that context.

Since sortBlocks are executed multiple times for each addition to the collection, it is recommended to keep the sortBlocks as simple and performant as possible is recommended; complex operations should be done outside of the sortBlock.

For further assistance, contact GemTalk Technical Support.