Introduction

ID Generator Tool allows one to increment a value stored in App Variable by one. It is often used to generate/keep a running number (e.g. application reference number) in your form.

ID Generator Field Properties

Configure ID Generator Tool

Figure 1: ID Generator Tool Properties

NameDescription
Form

Choose the Target form.

Field ID

Form field id. Only alpha-numeric and underscore characters allowed. Mandatory field.

If you use "id", the form will save with the "id" primary key in running sequence. Joget will not create the "id" in UUID format.

Record IDKey in the label of this field. Mandatory field.
App Variable Name

Name of the app variable to be used to store the running number. Joget will automatically create the app variable if the name does not exist. Only letters (a-z and A-Z), numbers (0-9) and underscore (_) are allowed in the App Variable Name field.

Do ensure your App Variable Names are unique for each form in your app (meaning for each form that is mapped to a different database table name).

If you are using the ID Generator Field as "id", meaning it is a primary key value, be careful not to override the app variable value when importing apps: do not click the "Show Advanced Options > Override app variables" checkbox in Import App screen.

Format

Determines the pattern of the generated value (e.g., "REF-?????" will yield "REF-00001").

Workflow Variable

The value generated can be saved into the corresponding workflow variable named here.

Using a non-existent Workflow Variable name

You will get the following warning with the name printed out (e.g. status) in the server Joget log if you attempt to map to a non-existent Workflow Variable:

context attribute status does not exist in process context - adding new attributes to the process context is not allowed

Distributed Unique ID

Generates a distributed sequential unique ID.

It is advisable to use Distributed Unique ID when dealing with high loads of ID generation to avoid performance bottleneck.



Isolation Level For MySQL Database

The isolation defines the way in which the MySQL server (InnoDB) separates each transaction from other concurrent running transaction in the server and also ensures that the transactions are processed in a reliable way. If transactions are not isolated then one transaction could modify the data that another transaction is reading hence creating data inconsistency. Isolation levels determine how isolated the transactions are from each other.

You will only need to do this if you are using MySQL, as other databases already default to "READ-COMMITTED".

Run following queries in MySQL.

SET GLOBAL tx_isolation='READ-COMMITTED';
SET SESSION tx_isolation='READ-COMMITTED';

You will also need to set the following in your my.cnf/my.ini file.
[mysqld]
transaction-isolation = READ-COMMITTED




  • No labels