Note some ideas
This commit is contained in:
commit
95985203f6
|
@ -0,0 +1,39 @@
|
|||
# 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?
|
Loading…
Reference in New Issue