Schrievkrom

Every platform has different needs – the same with Gemstone. For each target a programming model is needed. This programming model is created by offering a library for the programmer.

While the CodeGenerator under C# supports an internal RAM-database and is now more than 7 years old, the runtime is pretty large, old and has to manage the objects, the transactions and all that stuff.

The programming model for Gemstone is pretty simple – Gemstone offers most of the needed stuff out of the box: transaction management, object cache … it is more or less some exception classes and one root domain class – offering instance initialization support. That’s it.

This programming model is packaged as an Monticello-module “MSK-ModelBaseRuntime”.

Whenever I work on the Modeller the “latest” target always gets the newest feature (and the other targets have to wait – if at all they get the newest stuff). Due to needs I added enumeration-support in the modeller (to be able to model different state values) and that an association can not only be realized via an instance of OrderedCollection – but also via a Dictionary. Domain object instances then are added to this Dictionary by using a definable attribute of the objects being added.

This is very nice if you have a large number of instances managed by that association and via HTTP-REST-calls you have to do many look-ups via some unique ids. Dictionaries are faster than large OrderedCollections.

Plans for unordered collection are also waiting to be realized. This might be useful when working with indices – but that has to wait.

As a user I have now a running Gemstone, an opened modeller and Jade for editing the source code. In addition I have the monticello-based runtime library.

I have gemstone installed in a virtual machine and therefore its on the same machine.

Via VirtualBox/SharedFolders I always have a host-based Windows directory (e.g “sources”) available under Linux (/media/sf_transfer/sources)

Within Linux I have an open Topaz session waiting for my commands.

I start the modelling tool under Windows, make some changes and create the corresponding source code – the “gs”-file is written in the directory mentioned above.

Then I switch to my Topaz system, make – to be sure – an “abort” and then a


abort
input /media/sf_transfer/sources/webcati-modelsource-2014-02-14-10-40-37.gs
commit


and topaz is importing my source. Then do an “commit” to make the source code persistent.

Now doing an “abort” in Jade, you can edit the new source code.

Now to the restrictions when using this approach:

* the automatically generated model source code is contained in one package – or Monticello package. This will be overwritten with each new source code generation run. One must not change this code or add new stuff to it. It will get lost with new revisions of the model source code.

* instead the user is always working in another package – practically doing only extensions to the model package – using different method categories.

* One must not access instance variables via instance variables names, but only via accessor-methods. This is not automatically needed – but the problem is, that Gemstone – while recompiling methods – will find that perhaps the instance attribute is not available any more and throw away the source code of that method – because it can not be compiled by the compiler. I do not know if I can change Gemstone behaviour here. But I lost several methods with heavy logic code. Therefore I decided to change my programming way of accessing instance variables.

Now back to the code …