Spinalcore objects & Atomic objects_

SpinalCore manages data as objects that inherit from the class Model. This is true for the entities itself (for example, a book), but also true for the attributes of this entities (for example, the author of the book).

The Model class contains all the methods to store, modify, read, and delete the data.

Models provided by default

The JavaScript connector provides by default a set of object types that inherits from Model, ready to be used by the developers. These are:

  • Obj: generic object
  • Val: scalar object
  • Bool: boolean object
  • Str: string object
  • TypedArray: array of data treated atomically
  • Lst: array of objects inherited from Model
  • Vec: array of objects inherited from Val
  • ConstrainedVal: scalar with maximum and minimum

Below, there is a diagram showing the inheritance relation. Developers can use any of these objects or create their own ones.

Differentiating atomic and entity Models

An entity Model is a complex object which contains atomic Models as attributes. For example, a "Book" can contain different attributes: "title", "author" and "year". For SpinalCore, a Book is an entity model and its attributes are atomic models.

The entity Model is defined by the developer, and the only condition is that it should inherit, at some point, from the Model class. The atomic Model is provided by SpinalCore and must be one of the models provided by default (the ones listed above). In this way, when synchronizing the data, SpinalCore will only synchronize the atomic attributes that have changed, and not the whole entitiy objects.

For manipulating atomic attributes inside a Model, these methods must be used:

  • add_attr() for adding new ones
  • rem_attr() for removing them
  • mod_attr() for modifying their values

These methods will allow the system to create a tree-structure of Models, as it is shown in this diagram, following the Book example. The blue rectangles are objects while the white ones are properties, and the dotted arrows are references.

In the diagram, the BookObj is the entity Model, while its attributes (title, author and year) have a reference to Str and Val atomic Models.

Here there is a brief explanation about how the methods involved in the manipulation of the attributes work:

  • The add_attr() receives as an argument a "key, value" object containing in "key" the name of the attribute and in "value" the initial value. Note that there can be many "keys" and "values" on the same object for adding more than one attribute at once. What this function internally does, is converting each "value" in a new Model , assigning it to a property of the current Model, and adding the current model to a parent list of the new one. There is a third optional boolean parameter in this function called signal_change, which by default is true. Depending on its value, it will tell or not the system to schedule a synchronization in case it hasn't been done so far.
  • The rem_attr() receives as an argument the name of the attribute to be removed from the current Model. This function will first get the corresponding Model of the attribute, then it will remove the current Model from its parent list, and if there are no more parents, it will call also the attribute's Model destructor. Also, there is a third boolean argument called signal_change, which acts in the same way as in the add_attr() function.
  • The mod_attr() receives as first argument the name of the attribute and as a second one the new value. It will call first the rem_attr() and then the add_attr().
List of atomic models

The atomic Models are provided by SpinalCore, but they are rarely instantiated directly. Instead, the developer can define them as simple JavaScript data types (string, number, boolean, etc.) in the add_attr() method, and the ModelProcessManager will automatically convert them to Model objects.

The automatic conversion will work for the following data types:

  • array -> Lst
  • object -> Obj
  • number -> Val
  • string -> Str
  • boolean -> Bool
Readand Write data in atomic models
As SpinalCore doesn't work with native JavaScript data types, but Model instances, the way in which the developer reads or writes data into them is by means of the get() and set() methods respectively.
The _server_id

The attribute _server_id is a unique identifier of a Model but does change each time the SpinalHub restarts.


On Model Creation, the Model will get it's final _server_id when the SpinalHub server "acknowledges" the Model,

for that the Model will go through several mutations:

process

1Creation of the Model.The _server_id doesn't exist yet
2The Model is pushed in an existing model or stored as is. (Send a request to push the Model in the server)The _server_id is temporarily and is socked in FileSystem._tmp_objects object
3

The SpinalHub server "acknowledges" the Model and tells it to the Organ,

The _server_id is definite (until the next restart of the ServerHub) and is moved from the static attributes Object FileSystem._tmp_objects to the FileSystem._objects.