57 lines
2.0 KiB
Markdown
57 lines
2.0 KiB
Markdown
# ProcruSQL
|
|
|
|
## Goals
|
|
|
|
Declarative, Config declares how a schema should look like.
|
|
|
|
In most cases, procrusql should figure out what it has to do.
|
|
|
|
It must be possible to supply custom code, either because procrusql
|
|
doesn't know what to do or because it can be done in a cleaner or faster
|
|
way.
|
|
|
|
Data migrations must be possible, for example:
|
|
* A new column is filled with data from an old old column.
|
|
* A new table is filled with data from existing tables
|
|
* New data is inserted into the database. This may require using
|
|
intermediate results (e.g. inserting data into into a master table
|
|
returns a new PK which is then used for inserts as the FK in a
|
|
detail table)
|
|
|
|
Need some kind of dependency system (similar to make).
|
|
For example, if a migration requires creating a new table, copying data
|
|
from an existing table and then dropping the old column, we have to make
|
|
sure that happens in the right order.
|
|
|
|
Syntax should be easy to read and write
|
|
|
|
Syntax should be diff-friendly
|
|
|
|
All changes should be done in a single transaction.
|
|
|
|
It should be possible to use multiple database connections (for example,
|
|
installing functions in an untrusted language requires a privileged
|
|
user). Obviously, if we have several connections, we can't have a single
|
|
transaction.
|
|
|
|
## Non-Goals
|
|
|
|
Reverting changes (instead apply the old config again).
|
|
|
|
Performance. I expect the typical configuration to be small (dozens of
|
|
tables and hundreds of records, not hundreds of tables and millions of
|
|
records) and the use cases to be infrequent (a few deployments per day,
|
|
not many per second).
|
|
|
|
## Problems
|
|
|
|
Is the order of operations always the same or is it sometimes necessary
|
|
to do things in a different order depending on the current state?
|
|
|
|
## Random ideas
|
|
|
|
I think we should have empty nodes which are just used to group dependencies,
|
|
e.g. something like `table_x_complete` which depends on `table_x` and all its
|
|
columns, contraints, indexes, data, etc. so that other nodes can just depend on
|
|
`table_x_complete` and don't have to bother about the details.
|