52 docs tagged with "database"

The Genesis database supports:

Indices are key components of any database. In the Genesis platform, every table must have at least one index: the primary key. This is vital for controlling how data is read by an application.

Typically, such as in relational databases, a table is a data structure that organises data into rows and columns.

Views are defined in the -view-dictionary.kts files as discussed

The following objects and classes encapsulate your data within your Genesis application, so that you can process it and add value as you see fit.

DbEntity is the common interface implemented by table entities and view entities.

Using DbRecord instead of entities will circumvent compile-time validation of database interactions. This means that errors might not appear until runtime or might lead to unexpected results.

Index entities are nested in table and view entities. The name will be based on the index name. The entity can be constructed by passing in the field values in order. The first field of the index must always be provided, and the others are optional.

Table entities are classes generated by Genesis that match your applications's data model. The generated entity name is based on the table name, but will be camel case.

View entities are classes generated by Genesis, which match your application's data model. The name of the view entity that is generated will be the name specified in its definition, but it is converted from snake case to camel case; for example, VIEW_NAME becomes ViewName. All table/view entities implement a common interface called DbEntity.

There are two interfaces for handling database changes:

Optimistic Concurrency helps prevent users from updating or deleting a stale version of a record. To do this, we need to know what the intended version of the record to update or delete is. Internally, we use the record's timestamp field as its version.

Genesis supports different ways of interacting with the database. Regardless of the interface used, the operations remain the same. The recommended way of accessing the database is via the EntityDb.

The entity db enables you to interact with the database layer; you can use any generated type-safe entities for

IMPORTANT! From GSF version 7.0.0 onwards, code generation for database repositories is disabled by default. To re-enable code generation, change the generateRepositories setting inside the build.gradle.kts files for the genesis-generated-dao and genesis-generated-view modules, as shown below:

Using RxDb instead of entityDb or generated repositories will circumvent compile-time validation of database interactions. This means that errors might not appear until runtime or might lead to unexpected results.

Frequently asked questions

Genesis provides two database solutions built on FoundationDB.

Your Genesis application data model can be configured without any concern about the database technology used to store the model and the data.

If you want to use an SQL database for your Genesis application, the following technologies are supported:

This page is only for users of GSF version 7.1 or earlier.

This page is only for users of GSF version 7.1 or earlier.

This page is only for users of GSF version 7.1 or earlier.

The fields, tables and views you define must be turned into DAOs (Database Access Objects).

Helper classes allow you to access common functionality and domain state within the Genesis platform.

Entity Modify details

Entity write result

The API that you choose to use depends on:

The Consul cluster mode uses Hashicorp's Consul for service discovery.

DbMon is the Genesis database client. It provides a set of commands that enable you to view and change the database as necessary. DbMon hides the details of the specific database technology, so this does not affect your usage.

Database on a separate node

Remap is a schema-migration tool that applies the current schema (defined in the deployed field and table GPAL dictionaries) to the underlying database layer.

Genesis has numerous built-in commands that have their own individual functions.

This document describes the recommended uses of config management with Genesis frameworks. Readers must have some Linux system administration experience.

This section describes installing an application built on the Genesis low-code platform. Readers need to have some experience of Linux system administration.

This section is for users with experience of Linux system administration. Here we describe preparing a host to run applications built with the Genesis low-code platform.

When database updates are distributed, they are wrapped in helper classes:

Bulk objects are published to listeners of mixed read/subscribe operations. Like Record Update, Bulk is a sealed Kotlin class. It has the following class hierarchy:

Generic record update

This page is only for users of GSF version 7.1 or earlier.

Automatically generated sequences

This page is only for users of GSF version 7.1 or earlier.

Version 7.2 introduced a simplified table-dictionary syntax, where fields are defined inline in the table,

This page is only for users of GSF version 7.1 or earlier.

Simple table with autoincrement

Before version 7.2, Genesis you had to define fields in their own dictionary file, separately from tables.

The Genesis low-code platform relies on Kotlin coroutines for providing high-performance applications. The Async API is the preferred API for accessing the database in Kotlin. The RxJava API is also available. If you use Java, the asynchronous API is not available.

RxJava is a Java implementation of reactive extensions. The Genesis database uses this library to represent asynchronous database operations in java.

The blocking - or sync - API is the simplest API for accessing the Genesis database.

Derived fields

A view definition is made up of joins and fields.

Here is an example view-dictionary.kts.