-
Notifications
You must be signed in to change notification settings - Fork 9
Persistence
Ciera was built as a model compiler to build model compilers. Therefore one of the key design requirements was for it to be able to load and dump instances of the xtUML meta-model in the BridgePoint persistence format (SQL). Ciera has a built-in SQL loader/dumper generator, but also supports other types of loaders.
Projects can be generated with a SQL insert statement loader/dumper. Instances can be loaded from standard input or a file or set of files and be dumped to standard output or a file.
The loader/dumper can serialize and reload entire instance populations including stateful classes. In flight events and pending timers can be serialized and re-loaded.
To enable the SQL tool, first add the InstanceLoading mark with "Sql" as the
value. See Instance loading for mark details. Next add the sql tool as an
execution step to the project pom.xml. You will need to define an output
location for the core code generator so the instances can be loaded by the sql
tool to generate the loader/dumper. This file can be anything, but simply serves
as an intermediate landing location between the two code generators:
<execution>
<id>ciera-core</id>
<goals>
<goal>core</goal>
</goals>
<configuration>
<output>${project.build.directory}/b.xtuml</output>
</configuration>
</execution>
<execution>
<id>ciera-sql</id>
<goals>
<goal>sql</goal>
</goals>
<configuration>
<input>${project.build.directory}/b.xtuml</input>
</configuration>
</execution>
To use the SQL loader/dumper, you must make calls to the SQL external entity.
SQL::load();
will load instances from standard input.
SQL::serialize();
will write the instance population to standard output. More detailed documentation can be found in the API docs
The SQL loader/dumper tool can only generate loaders and dumpers for class models with attributes of the core types and enumeration types. User defined types and structured types are currently not supported, however attributes typed with user defined types can be marked as non-persistent and therefore the instance population can still be loaded excluding those attributes.
The SQL loader/dumper tool only supports class models with all formalized associations. Supporting unformalized relationships is a goal for the future, however it may never be part of the SQL loader/dumper and may be part of a different loader/dumper utility.
Although multiple files can be loaded, the loader expects all related instances to be loaded at once. Because of this, multiple file support is not as useful because the populations held by the individual files would have to be disjoint.
Similarly, serialization only supports dumping the entire population at once (to standard output or a file).
Ciera provides an API for writing extremely customizable population loaders. This feature is intended to support any type of loaders, but especially loaders based on parsing a natural modeling language.
The API consists of two parts. An external entity call that can be executed in an OAL action to hook into a hand written Java class and pass an argument list, and a set of bridges that allow hand written code to create and manipulate instances from hand written code.
The details of this API can be found in the LOAD external entity API docs
Ciera has been written in a way to support implementation of other types of loaders in the future. Ciera could even support multiple types of instance loaders for a single project.
The instance loading mark registers an instance loader for a component. For SQL instance loading, this is required with the value "Sql"
<component_name>,InstanceLoading,Component,<loader_id>
ex: pei::pei,InstanceLoading,Component,Sql
where <component_name> is the double colon delimited path to the xtUML
component (not including the project name), and <loader_id> is the identifier
of the specific instance loader/dumper. Currently the only supported value is
"Sql".
By default, SQL loader/dumpers will be generated to load and dump architectural instance IDs. The architectural IDs are required to load instance populations with pending timers and in flight events. To disable architectural ID persistence, add the following mark:
*,NonPersistentInstanceIds,*,true
To exclude an attribute or class from persistence, add the following mark:
<path>,NonPersistent,Attribute,<exclusion_type> <path>,NonPersistent,Model Class,<exclusion_type>
ex: ooaofooa::Instance::Timer::expiration,NonPersistent,Attribute,load_only ooaofmarking::Markable Element Type,NonPersistent,Model Class,true
where <path> is the double colon delimited path to the xtUML class or
attribute (not including the project name), and <exclusion_type> determines
how it is excluded. For classes "true" is the only acceptable value. For
attributes, "true" causes the attribute to be completely excluded from the
schema. "load_only" keeps the attribute in the schema, but excludes it from
load. At load time, the attribute will be assigned the default value of its type
and at serialization, the attribute’s value will be serialized normally.
< prev: Build | next: Templating >