2.3 KiB
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.
I don't have a good ideas for data changes yet. For example I may want to change the value of a (non-PK) column for one or more rows. Easy in SQL, not easy in a generic way without reinventing SQL. Idea for the simple case: data_update key={} new={}. Maybe allow arbitrary SQL for the complex case. But must be idempotent.