Storable - Xyna-Factory/xyna GitHub Wiki

A Storable is a special Data Type having xnwh.persistence.Storable declared as its Base Type. xnwh.persistence.Storable can be found inside of the Standard Application named Base.

Storable instances are objects with values that are persistent inside of the Xyna Factory (e.g. in a data base). A Storable instance instantiates a specific Storable Data Type. Once instantiated, it can be stored in and retrieved from the persistant storage and it can be manipulated.

Please note: Changing a Storable affects the existing instances of that Storable (see below for details).

There are three Modeling Blocks to do these operations from out of a Workflow:

• Store Storable
• Query Storable
• Delete Storable

Table of Contents Create a Storable Storable Role Unique Identifier Historization Storable Properties Referencing Indexing Uniqueness Constraint Change a Storable Good Changes Problematic Changes See Also

Figure 1
(A) ''xnwh.persistence.Storable'' as base type, (B) available Storable Roles, (C) Show Data Type Details of Storable, (D) enable historization

To create a Storable you need a new Data Type by the New Document symbol in the left icon bar. As mentioned above, declare xnwh.persistence.Storable as the Base Type of your Data Type to make it a Storable (fig. 1 (A)).

Please note: Extending a Data Type that extends xnwh.persistence.Storable is not supported.

Once declared, there are some extra properties distinguishing a Storable from a common Data Type:

For each Member Variable you can configure the role in the Member Variable's details.

Each Storable has to have exactly one Member Variable with the role Unique Identifier (fig. 1 (B)).

If you deploy a Storable without a Unique Identifier, an additional Member Variable will be created automatically.

Two Member Variables with the Storable Roles Current Version Flag of type boolean and Historization Time Stamp of type long (fig. 1 (B)) are needed for historization. Current Version Flag = true marks the currently relevant version, Historization Time Stamp serves to secure the time of historization. Use historization in the detail area of the Data Type (fig. 1 (D)) is enabled exactly when this two Member Variables exist.

The Storable Properties are read-only.

A Member Variable that is a Storable itself can be used by a reference. In case of Reference = true, one Member Variable instance can be shared by many Storable instances. Otherwise this Member Variable is only accessible via the owning Storable instance.

If Index = true for a Member Variable, the search by this field will be accelerated while more indexing data has to be generated on the storage, though.

If Unique = true, the Member Variable's value occur at most once over all instances.

Be careful when changing Storables, because this affects its instances. Changes that work without problems are described as Good Changes, others as Problematic Changes.

• Adding new Member Variables to Storables
• Changing the Data Type of a Member Variable to compatible Data Type (e.g. int to Integer, long, Long, double, Double or String)
• Enabling historization by adding Member Variables for the Current Version Flag and the Historization Time Stamp

• By knowing the exact content of the existing instances a conversion could be done without problems. For example a conversion from String to int might work, if the strings already have number format and the storage does support an automatic conversion.
• Deleting Member Variables and all other kinds of changes not mentioned above may come along with loss of data of instances. You can compensate such changes by manipulating the storage by hand, which takes knowledge of the concrete storage structure on Xyna Factory.

• Storable Instance Management in the Factory Manager
• Storable Management via CLI
• Modeling Blocks
• Data Type
• Modeling