50 docs tagged with "database"

The Genesis database supports:

Indices are key components of any database. In the Genesis low-code platform, they are mandatory when you define a table. Every table should have at least one index, the primary key. This is vital for controlling how data is read by an application.

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.

This section provides you with details about the three types of operation that you can perform on the database.

Genesis supports a number of different read operations. Although the specifics vary between the different interfaces, the underlying principles remain the same. This page explains these principles, without going into specific calls.

Subscribe operations enable code to react to database changes, rather than polling for changes. Code can either listen to changes, or use a combined read/subscribe operation. These mixed read/subscribe operations are useful.

The following database operations are available:

Genesis supports different ways of interacting with the database. Regardless of the interface used, the operations remain the same. The preferred 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

During the code generation phase, repository classes are generated for every table and view in the system. These repositories provide a type-safe way of accessing the database.

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.

Genesis supports Aerospike. To connect to Aerospike, use the system definition items listed below.

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:

Modularity

Field types

There is no complexity to a fields-dictionary.kts file.

Introduction | Fields | Tables |

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

Entity Modify details

Entity write result

Once you are happy with your data model, you can build your database.

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

DbMon is the Genesis database client. It provides an interface to the underlying database and hides the details about the specific database technology. Generic database clients can be used with the Genesis low-code platform, but we recommend that you use DbMon. This page gives details of all the DbMon commands and provides practical examples of how you can use them.

Database on a separate node

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

This document describes the recommended uses of config management with Genesis frameworks. It is written for readers with 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

Subtables

In your application's tables-dictionary.kts file, you need to define every table that your application needs. Let us look at a very simple example definition. This contains a single table with three fields in it.

Our example below shows an application's tables-dictionary.kts file containing two tables. The first contains trades and the second contains simple position information for each instrument.

This section outlines two types of API for interacting with the database:

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.

Fields

A view definition is made up of joins and fields.

Here is an example view-dictionary.kts from our tutorial.