Gemstone/S – A Dead Item in a SortedCollection – What the hell is going on …

In our main product – in progress of development – we had a situation, where items in a SortedCollection could not be removed. From time to time we had these instances and I was not very happy about them.

The instance of SortedCollection had a sort block like: [:a :b | a getDoubleValue < b getDoubleValue ] – that means, that the sorting is based on an attribute of those elements hold in that collection.

The reason why the elements could not be removed was pretty soon clear: the attribute values (which the sorting is based on) had changed and the rules are pretty clear: if you change an attribute which is used as the sorting attribute somewhere you should remove the item from the SortedCollection. Change the attribute value and add it again to the SortedCollection instance.

Actually I was surprised to see, that these errors never popped up with an exception, but the PUM generator generates “remove:ifAbsent:[]” in the Topaz based server source code statements, so this error has been catched. Actually the question remaining was: “Who changes this value ?”. The attribute value was a double value and it was never intended to change very often or at all.

The structure of the application we developed here was an API driven application. The Browser-Frontends call the API, send some data (via JSON) and change them. The exchange of the update-API calls were done in that way, that ALL attributes were send to the database – regardless if they have changed or not.

The values of the attribute values therefore were also send from the server to the client and back to the server again – and we found the error: Gemstone/S prepared the string representation of the double value and put that string into the JSON representation, which was sent to the client.

The cliented presented the data, the user did some changes and the values got back to the server – and from time to time, the string-presentation changed (the user had no chance to change this value) , when the client (Javascript float -> string) sent back the data to the server. Not always, but sometimes and NOT very much – perhaps only the last digit changed.

But for Gemstone/S the little change was enough – the item could not be removed from the SortedCollection again. One could trigger a resort, but with 500.000 elements in that Collection this is not a nice way to go …

Another way to get rid of this error was to mark this attribute in the PUM editor as “client-readonly” attribute, which generates code in the server in that way, that changes of that attributes are never transferred to the stored domain object from the API transfer object.

This entry was posted in Smalltalk and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s