Support for entities and inventories
The diesel domain modelling supports modelling of entities and their relationships. Entities (or assets) have a default JSON representation, they belong to a class
and have a key
and are persisted and managed by an inventory
or domain plugin
. These inventories can be defined in a few ways:
diesel.db.inmem
diesel.db.elk
which resolves down to HTTP callsdiesel.db.postgres
You can define classes part of Domain Modelling and bind them to inventories. After that, you can simply use these as entities in flows with CRUD messages, browse them with the built-in diesel browsers etc
Client messages when using the entity support:
""
or use "default"
as the connection name.Entity CRUD:
Example (see more in diesel-inv-story):
$send diesel.inv.upsert (class="TestClass1", entity=tc1)
$send diesel.inv.find (class="TestClass1", key="1234")
$send diesel.inv.delete (class="TestClass1", key="1234")
also with type-aware objects:
$send diesel.inv.upsert (entity = new Student {name: "Joe"} )
or:
$val x = students map x => diesel.inv.upsert (entity = x as Student) // the type of array is lost atm, known issue
If the class
can be inferred, it can be left out when calling diesel.inv.upsert
(for instance the entity knows it's class - see creating new Student above).
The query
and listAll
return a structure with two fields:
To use inventories, you need to make sure we know which classes are going to which inventory and that inventory uses which connection (in case there's multiple connections).
A connection is how an inventory connects to a specific database or storage system / API etc. Each inventory is responsible for managing its connections.
The first step is to connect an inventory you created or one built (other than the built-in inventories):
$send diesel.inv.connect(inventory="diesel", connection="default")
After that, you can register in many places all the classes you want to use that inventory:
$send diesel.inv.register(inventory="diesel", classes="TestClass1")
or by annotating the class:
$anno (inventory = "diesel")
$class TestClass1 ()
These are normally done in the Environment settings, which are executed when loading your app. The sequence should be:
You can only have one connection per inventory per env. See about multiple environment support in Environment settings.
$send diesel.inv.connect(inventory="diesel", connection="default", env="local")
The way this normally works is that when connecting, a connection will require connection information. This information is configured per environment, in Environment settings before the connection is created, with the diesel.setEnv message.
See the rules-based inventory implementations in diesel-inv-spec for examples of implementing rules-based inventories.
For instance, you will implement a rule like diesel.inv.impl.upsert
where the inventoriy matvhes the one you're implementing:
$when diesel.inv.impl.upsert(inventory == "my.inventory", className, table, key, assetRef, entity)
=> (k = key || assetRef.key)
=> (e=entity + {"assetRef":assetRef})
=> ... implement the creation in storage
=> (payload=entity)
You can use these to extend and implement your own repositories.
These are built-in.
diesel.db.inmem
- in memory, per userdiesel.db.memshared
- in memory, per appdiesel.db.col
- persisted in the built-in MongoDB, available for paid accounts, depending on volumesdiesel.db.postgres
- persisted in a Postgres DB that you need to providediesel.db.elk
- persisted in an Elastic DB that you need to provideYou need to log in to post a comment!