Data Storage Concepts
This topic provides high-level descriptions of important concepts in LogicNets.
Projects, Packages, and Applications
In LogicNets, you create a project and publish it, and a published project is called a package. The package that is started by the user in runtime is called the application. A package typically contains business content, but there are also special types packages, including frameworks and libraries.
A framework is a package that you reference from application package, and that application then inherits all of the functionalities and features offered in the framework. You can also stack frameworks in layers; for example, you can create a framework that is built using another framework. When a user starts a application package, the system loads its referenced framework as well as any framework referenced by it. Most frameworks cannot run without an associated application package.
A library is package that contains reusable logic, such as business content and functional logic. You can reference library packages from other packages, much like DLLs are used in Windows.
You can create a project and then update it and overwrite it in the publishing cycle while using the same name as the original package. However, there are times when you might publish a project multiple times, giving each package a new name but the same category name. The category name is the name of the project in the Designer. You can install and activate these different packages at the same time on the same system, although, by default, only the most recently installed package per category is active. You might typically use this setup when multiple versions of the same project need to be installed on one system.
By default, LogicNets supports the following database sources:
|Read-only resources (current package scope)||Tables defined in ‘Read-only resources’ are private and part of the package itself. Therefore, at run-time, these tables are read-only and cannot be modified.
Typically, tables in ‘Read-only resources’ are lookup tables, which are created and populated during design.
|Package Data (current package scope) (Release 7.4+)||Tables defined in ‘Package Data’ are private to the package. In contrast to ‘Read-only resources’, these tables can be modified at run-time, and all data is preserved when the package is updated/reinstalled.
Typically, you can use tables in ‘Package Data’ for storing package-specific data like configurable user settings and results.
|Application Data (application scope) (Release 7.4+)||Data in this source is stored in an application-package-specific database. An application package is the package that is started, an application package is the most derived package in a session. All packages in the session can define data tables that are stored in application-package-specific databases. For example, a framework can define a data table in this source to store data that is only shared between sessions that are started with the same application package.
The system does not touch the data in this source when the system is updated.
|Session (Session scope)||Tables defined in ‘Session’ are private to the package and session. Namely, each session will have its unique session database in which these tables will be created.
Typically, tables in ‘Session’ are used for storing temporary data.
|Data (company scope)||
Tables defined in ‘Data’ are accessible by all packages in the same company. The data is preserved during installation, reinstallation, and upgrade.
Each time a user starts an application, the LogicNets runtime checks for the existence of the defined tables in the connected database sources. If a table does not exist the system creates the table according to the definitions in the LogicNets project.
When the system first creates the table, it is empty. However, from Release 7.4+, and subject to the exception below, it is possible to define default data records for the these tables, and the system will add these records to the tables after creating the tables themselves. The system does not update the default records in the data source when default records are updated, deleted, or added in the Designer.
The exception to the above is for tables in “Read-only resources”. This type of table does not support default data records. The tables in the ‘Read-only’ resources are populated during design and no defaults are applicable.
Updating Table Definitions and Data Migration with Upgrades
When a package is being updated, the system automatically updates the database schema of the tables/views to the latest definition. The system adds new columns, deletes old columns, and recreates views. It also updates default records.
Additionally, when a newer package of the same category is installed, the system copies the data from the ‘application’ and ‘package’ data databases of the existing package to the ‘application’ and ‘package’ data databases of the new package.
LogicNets Table Name vs. Database Table Name
The name of the table/view definition in your LogicNets project must be unique, and it is the logical name for the table/view in the database. By default, the table/view in the database has the same name, but it is possible for you to specify a different name. You might do this in the following situations:
When the table/view exists in an external database management system. Typically, enterprise databases use namespaces or other structures to organize the tables/views. In that case, the real table name may need to have as a prefixed the namespaces.
- The logical table name is an alias for tables with different names in different databases.