procrusql/Notes.md

57 lines
2.0 KiB
Markdown
Raw Normal View History

2022-01-28 12:49:22 +01:00
# 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.
2022-01-28 12:49:22 +01:00
## 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).
2022-01-28 12:49:22 +01:00
## 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.