Skip to main content

Settings

apps#

Default: [] (Empty array)

Djorm borrows the concept of apps from Django. Some apps require initialization before they can be used. Reference them inside djorm settings so it can initialize and shutdown apps when the moment is right

databases#

Default: {} (Empty object)

Configure database backends your application will communicate with. Key can be referenced in models to determine which database will be used.

The simplest possible settings is for single database setup using SQLite. This can be configured using following:

configure({
databases: {
default: {
driver: 'djorm-db-sqlite',
path: 'database.sqlite'
}
}
})

When connecting to other databas backends, such as PostgreSQL, MariaDB or MySQL, additional connection parameters will be required.

Usually you'll want to have separate configuration for local development and your other environments. Use environmental variables for that.

driver#

The database backend to use. Here are some of the supported drivers:

connectionMaxAge#

Default: 0

The lifetime of a database connection, as an integer of miliseconds. Use 0 to close database connections at the end of each request and null for unlimited persistent connections.

password#

Default: null

The password to use when connecting to the database.

port#

Default: null

The port to use when connecting to the database. Use null for the default port.

user#

Default: null

The username to use when connecting to the database.

logger#

Djorm uses Pino.js internally as a logger. This configuration is passed directly to the logger.

level#

Default: 'info'

Pino.js level, the logger will display messages with severity same or higher to this setting.

transport#

Default: null

You can customize the transport that delivers your logs by specifying a require path.

secretKey#

Default: '' (Empty string)

A secret key for particular Djorm installation. This is used to provide cryptographic signing, and should be set to a unique unpredictable value.

Warning

Keep this value secret.

Running Djorm with a known secretKey defeats many of Djorm's security protections, and can lead to privilege escalation and remote code execution vulnerabilities.