How to work with Rivery CLI?
Rivery CLI is an amazing way to manage, deploy, run and edit rivers inside Rivery.
The rivers are configured only by .yaml
files, as a configuration files, makes this CLI as a basic
of Infrastructure As Code (IaC) methodology.
Rivery CLI is a project based command line tool, what means the command line knows to work and operate under every directory
has a project.yaml
file under it. The project.yaml
file provides the
A project is a directory includes .sql
and .yaml
reference files, which represents infra entities, references and connections between them,
what makes the management and handling entities in Rivery (rivers/connections) connected in one place, and can be done using Infrastructure As Code (IaC) methodology.
In order to start new project, please check out this project's getting started guide.
Referencing between entities
When you configure and manage your entities, it is common to have some features which you use across several of resources. In that case, you can create a snippet for such elements in order to use them multiple times when you need it and manage them in one place. Rivery CLI provides a quick and easy way to manage entities, using a fragmented, isolated and independent references per each entity, or even per specific parts in the entities, like table references, sql clauses, variables, and references.
The !ref
key
The basic reference key is the !ref
key.
Using !ref
provides to create a reference (which actually concatenate) another pieces of yaml
files across.
For example, supposed you have a large logic entity, and you want to manage its steps in file-per-step structure. In this case, you may want to have a structure like the next:
1 2 3 4 5 |
|
Therefore, in order to manage each step in its own yaml file, you can create a 2 step.yaml file that will look like that:
1 2 3 4 5 6 |
|
1 2 3 4 5 6 |
|
and connect them in the main container
definition with !ref
key:
1 2 3 4 5 6 7 8 |
|
The !sql
key
Managing sql clauses inside yaml files are not the easiest and nicest thing to perform. Therefore, in most cases, it's recommended
managing SQLs in separated files, one per a query. An important ability using SQL files in separated files provide is version management using any version-control tool, such as git
.
For these cases, you can create the a .sql
file under the sqls
dir configured in the project.yaml
, and use
its reference on entities/mapping yaml
files. The reference for using an sql query file is deteremnined by the
!sql
key. Moreover, using this reference provides you the way to manage the same sql query with more than one
logic entity.
For example, think you have a project included entities yaml with a couple of steps:
1 2 3 4 |
|
logic.yaml
file contains 2 sql query steps:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Therefore, instead of managing these sql inline in the yaml files, you can separate them into independent files:
1 2 |
|
1 2 |
|
The files will lay under the sqls
dir as defined in the project.yaml
and can be also combined under dir by their business significance :
1 2 3 4 5 6 7 8 9 |
|
and create a reference in your yamls to your files:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|