40 lines
1.3 KiB
Markdown
40 lines
1.3 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.
|
||
|
|
|
||
|
|
## Non-Goals
|
||
|
|
|
||
|
|
Reverting changes (instead apply the old config again).
|
||
|
|
|
||
|
|
## 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?
|