Data Structures

Overview

In the context of a cloud toolkit, the term Data Structures refers to the domain model of an application. The actual entities in a domain model directly correspond to the underlying database entities, that is, tables and views. There is no additional abstract layer between the code of your application and the actual model in the target storage.

Tables

Table Model is a JSON formatted *.table descriptor. It represents the layout of the database table, which will be created during the activation process.

Example descriptor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
	{
	  "tableName":"TEST001",
	  "columns":
	    [
	      {
	        "name":"ID",
	        "type":"INTEGER",
	        "length":"0",
	        "notNull":"true",
	        "primaryKey":"true",
	        "defaultValue":""
	      }
	      ,
	      {
	        "name":"NAME",
	        "type":"VARCHAR",
	        "length":"20",
	        "notNull":"false",
	        "primaryKey":"false",
	        "defaultValue":""
	      }
	      ,
	      {
	        "name":"DATEOFBIRTH",
	        "type":"DATE",
	        "length":"0",
	        "notNull":"false",
	        "primaryKey":"false",
	        "defaultValue":""
	      }
	      ,
	      {
	        "name":"SALARY",
	        "type":"DOUBLE",
	        "length":"0",
	        "notNull":"false",
	        "primaryKey":"false",
	        "defaultValue":""
	      }
	    ]
	}

The supported database types are:

  • VARCHAR - for text-based fields long up to 2K characters
  • CHAR - for text-based fields with fixed length of up to 255 characters
  • INTEGER - 32 bit
  • BIGINT - 64 bit
  • SMALLINT - 16 bit
  • REAL - 7 digits of mantissa
  • DOUBLE - 15 digits of mantissa
  • DATE - represents a date consisting of day, month, and year
  • TIME - represents a time consisting of hours, minutes, and seconds
  • TIMESTAMP - represents DATE, TIME, a nanosecond field, and a time zone
  • BLOB - a binary object, such as an image, audio, etc.

The activation of the table descriptor is the process of creating a database table in the target database. The activator constructs a “CREATE TABLE” SQL statement considering the dialect of the target database system. If a particular table name already exists, the activator checks whether there is a compatible change, such as adding new columns, and constructs an “ALTER TABLE” SQL statement. If the change is incompatible, the activator returns an error that has to be solved manually through the SQL Console.

Views

View Model is a JSON formatted *.view descriptor of a database view. It is usually a combination of multiple tables and is used for reporting purposes. The script should follow the SQL92 standard or has to be aligned with the dialect of the target database.

Data Files

Delimiter Separated Values (*.dsv) data files are used for importing test data during development or for defining static content for e.g. nomenclatures. The data file name has to be the same as the target table name. The delimiter uses the `|` char, and the order of the data fields should be the same as the natural order in the target table. If you want to import particular data only once, this can be done via the Import Data wizard.

Be careful when using static data in tables. Entity Services (generated by the templates) use sequence algorithm to identity columns starting from 1.

The automatic re-initialization of static content from the data file can be achieved when you create a *.dsv file under the DataStructures folder of the given project.

To make it more flexible in 2.7 it is introduced semantic files as follows:

  • REPLACE (.replace) - the rows in the database table always correspond to the lines in the data file. Processing of this type of files means - first delete all the records in the database table and insert the rows from the file. This is the behavior of the initial format - DSV (.dsv). The processing is triggered on restart of the App/Web Server or on publishing of the project containing these files.

  • APPEND (*.append) - the rows from these files are imported only once into the corresponding database tables. If the tables already contain some records the inserting is skipped. After the initial import the corresponding sequence is set to the max ID of the table, so that this table can be used afterwards as persistence storage for the e.g. standard CRUD Scripting Services.

  • DELETE (.delete) - if the file contains ‘’ as the only line, the whole table is cleaned up. Otherwise only the listed records got deleted by the ID (first column = ID = primary key).

  • UPDATE (*.update) - the records in the database table got updated with the corresponding lines in the data files. The first column is the ID = primary key used as selection parameter for the update clause. The existing records in the table are not deleted in advance as at the REPLACE case. If no record exist by the given ID, it got inserted.

Edit