In our Gemstone projects we have used the same strategy: the data is located in a tree structure – started from a root. We have no large structure (e.g. index bag) where one simple lookup will find the object.
During REST calls we therefore have the need to find the objects in that tree structure.
This is – how I call it – a search path. The search path goes from the root via several multiple-/single-cardinality associations and leads us to the object we are are looking for.
The parameter of the REST calls therefore has to deliver the needed ids to find the objects in the numerous multiple-cardinality associations contained in the search path.
PUM now allows to define searchPath attributes (normally in the project class, where the data root is located) and it creates the needed access methods in various classes.
The Python code generator proved to be very useful.
We generated the REST client code for our production system in Python. Then we programmed a simple user simulator tool in Python (login, do several actions and then after some time: logout and repeat …).
Wonderful: it worked out of the box. Then we transferred the files to our multiple Raspberry PIs available and started the code there. Worked out of the box or to be more precise: concurrency errors showed up at once.
With these results we entered Gemstone programming again and changed the behaviour of the Zinc REST server and introduced automatically repeats of requests and at the end of the day we had only a few errors coming up in the clients – due to concurrency. That seems to be ok.
In our case one PI has to capacity of simulating around 50 concurrent users – we have 5 PIs here available for a testing system … will be fun.
Today I added the generation of all defined enumeration values to the Python code generator, which improves the readablity of the client REST code.
Another feature of PUM is the possiblity to define derived attributes in a class.
Derived attributes are attributes, which are accessable in object A, but the value is defined in another object (object B), but there exist an access path from A to B via various associations over (perhaps) multiple objects.
These definitions can also be used in index definitions. Due to the cardinality of the associations you can be pretty sure if you get a value from that access path or nil (this knowledge is needed when defining an index).
Posted in Smalltalk
Tagged Gemstone, PUM
Same procedure as yesterday … take the runtime of swagger for C# and produce support files for this language … within a day I have a binding for our REST system in C#.
The procedure creates a single file with all classes (for data) and for the API class with all functions you need to do calling the REST API.
To make a new project work you have to do the following steps:
- Please add ApiException,cs, ApiInvoker.cs from Swagger-CSharp Runtime to your project
- Change the namespace of Apiinvoker and ApiException according to your needs
- Add System.Web, System.Web.Extensions as reference to your application
- Your .NET Application uses the full .Net System – not the Client-only profile
- Add Newtonsoft.Json.Net40 to your solution
I tried to produce Python3 code via Swagger – but was surprised to see, that swagger-ui and swagger-codegen have slightly different opinions about how to interpret my swagger stuff. I had to patch my produced files to let codegen produce the Python3 code.
I looked at the produced code and in general this code was pretty simple. I decided to use the swagger-Python3-runtime, but produce all other files (API calls, class structures) via PUM.
Adding some cookie support to the swagger-Python3-runtime and after one day of work the first programs could be written to query our Gemstone/REST system via python.
As an IDE I used the community edition PyCharm (from JetBrains) and added lots of type hints to the produced code, so that PyCharm was able to offer Intellisense support.
The reason for the choice of Python was pretty obvious: large community, large infrastructure and an accepted language.
Now some information about current development for my modelling tool “PUM” regarding the code generator for Gemstone/S. This is work in progress – and I’m working on our product model with these new features.
Gemstone/S supported versions
I now only support the newest version 3.2.6 of Gemstone – due to the newly introduced index-concept. There was no need here to stay for 220.127.116.11 and other versions. Its the one we are working now with.
For each defined associations the user may now define indices – based on attributes of the instances hold in that association. Supported structures for associations are now: Set, Bag, OrderedCollection, Array, SortedCollection with various options. “large”, “conflict”, “identity” and so on. Not all combination are valid.
When a new instance is created it now also creates ALL defined indices for that instance.
Utf16 attribute support
Up to the current version only the “type” “String” was allowed for a character collection attribute. Now its also possible to define “Utf16″ as a type – and the setting method ensures, that a needed conversion is done before storing a new string into that UTF16-based attribute. Utf16 attributes may also be used for index stuff.