WEM Storage Options
Last updated
Last updated
The WEM platform offers several distinct storage mechanisms for your application data. In this article we will discuss each of these options and what to consider if you intend to use them.
Concepts are typically used in WEM for Single Selects and Multi Selects: fields in your data model that should accept a limited list of pre-defined items. They are also used for Tab Bars (which is a specific display-form of a single-select field).
Organizing the data structure: The ontology (wiki) allows you to organize data in a tree structure. Each data element is represented as a node in the tree. These nodes are referred to as concepts. Attributes of the data item are represented as properties on the node. You can add custom properties on a specific level and determine the level to which the properties apply. Beyond organizing the data in a tree structure of concepts, it is also possible to create custom relationships between the concepts therewith creating a relational graph of concepts. Using a Concept Query, which is basically a graph query, you can retrieve specific concepts from the ontology. The Ontology provides a powerful feature in WEM, usable as basic Single/Multi select options or tabs, or moving towards more complex cross-related elements to steer application flows or provide multi-leveled cases.
Data availability: The information in the Ontology Concepts is available at the time of development, which allows you to include the actual data directly into your application logic.
Modifying data: The concepts, their properties and relations can only be modified during development time within the Modeler. During execution of the application in the Runtime Environments (Preview, Staging, Live) the information is read-only.
Data persistence: The data is persisted during the time of development in the Modeler, as part of the Project information.
Data accessibility: The data is accessible to all Modeler Sessions with access to the project, and read-only in User sessions in the Runtime.
Use case: This storage is perfect fit for data that describes the "conceptual domain" of the application. For example when creating an authentication/authorization system, the different kinds of user roles and privileges can be described using the ontology. This data is static in nature and will be included when modeling the access control logic of the application.
Organizating the data structure: In WEM, "Entities" (like Users, Books, Companies - multiple elements that have the same properties) are defined using Lists, in which an Entity instance (a specific User, a specific Book...) is a Row of the List. For example a list of people can be stored as a List named "Persons" and storing each person in the list as an instance by creating a row in the list. Entities can be nested to create parent/child relationships between the container entity and the nested entity. The amount of nesting is limited to 5 levels deep. Entities can be related one-to-many, by adding a Reference Field into a List (the many-part) that references another List (the source or the one-part in the relation). For example Books that contain a reference "Writer" to list Persons. Entities can also be related many-to-many using Lists that have Reference Fields to the other Entity-Lists that need to be related this way. For example a list BooksWriters that contains a Reference to Books and a Reference to Persons.
Data availability: During the time of modeling your application you can only define the schema/structure of the entity, creating the List and adding the Fields you will need for storing the actual data. Storing the actual data is only possible during the usage of the application in the Runtimes. The actual data is therefore not present in the Project during development in the Modeler.
Modifying data: The data can only be read and modified using the Application in the Runtimes.
Data persistence: Transient Lists hold information that is only available for the duration of the session and also only accessible to that session (single user, single time). Information stored in Persistent Lists will be stored in a specific Database, making the data available beyond the duration of a session (many users, many times). Note that when information is added to an Persistent List during a session, it will only be persisted when the changes are saved to the database using the Save All Changes node.
Data accessibility: Information kept in a Transient List is only accessible to the session of the user who added it (single user, single time/session). Information stored in a Persistent List and saved to the database, is accessible across all sessions of the application. Note that information added to a Persistent List but not yet Saved to the database, is only accessible to the user in the session where it was added or modified.
The total set of data for the application can be organized by using the Ontology Concepts for the static information of the data and Lists for the dynamic information (Runtime Data). For example when creating an authentication/authorization system, the Type of users, user Roles and Privileges can be defined in the Ontology as Concepts and the actual User instances can stored in a "User" List. In the User List you can add Single Select or Multi Select fields, based on the Concepts in the Ontology to store per User row which Type it is (Single Select), which Roles and Privileges the User has (Multi Selects). When this information is saved to the database, each User-Row will have a "reference" to the definition of the selected Concepts.
