Migration object graph #18
Description
We should be able to express a migration as an object graph or hierarchical tree of nodes.
The nodes in the graph will define things like operations or decisions, and allow expressing the steps needed to apply a migration.
When supporting a database engine, that engine will need to be able to "render" all of our supported operations into SQL native to that engine.
Conditionals
| Name | Graph | MSSQL | Postgres | MySQL |
|---|---|---|---|---|
| IfExists | #19 | |||
| IfNotExists | #20 |
Operations
| Name | Graph | MSSQL | Postgres | MySQL |
|---|---|---|---|---|
| Create | #26 | |||
| Drop | #28 | |||
| Alter | #27 |
Definitions
| Name | Graph | MSSQL | Postgres | MySQL |
|---|---|---|---|---|
| Table | #21 | |||
| Column | #22 | |||
| Index | #23 | |||
| Stored Procedure | #24 | |||
| View | #25 |
Expected Outputs
- A bunch of "nodes" for building the migration tree
- Ideally, we could express an entire database schema with this, not just a singular migration. This can be the basis for reverse-engineering schemas from different methods.
- This will then inform the abstract class (likely variation of the Visitor pattern) for traversing the graph and generating the SQL, which would then be implemented by each supported database engine.