Implement the drop_constraint operation
#103
Conversation
Add examples of dropping `CHECK` and `FOREIGN KEY` constraints.
| if o.Up == "" { | ||
| return FieldRequiredError{Name: "up"} | ||
| } | ||
|
|
||
| if o.Down == "" { | ||
| return FieldRequiredError{Name: "down"} | ||
| } |
There was a problem hiding this comment.
dropping a constraint is in many cases an easy operation, you land on a less restrictive schema but the old one keeps working. I wonder if these should be optional?
There was a problem hiding this comment.
In the case of removing a constraint the down SQL is the important one as that's the one that goes from a less restrictive schema to a more restrictive one. In the absence of data quarantine, it's necessary to ensure that values inserted into the new schema can successfully be written to the old one.
Theup sql could probably be made optional as it's almost always going to be a straight copy of the value from the more restrictive schema to the less restrictive one.
There was a problem hiding this comment.
PR here to make the up SQL optional: #106
I believe we will need this anyway, for instance to validate that the migration makes sense (the constraint exists?). Also, if you think about exposing postgres schema to Xata users, probably our internal representation is a great candidate for this. |
Agreed, it would be useful for migration validation if nothing else.
You mean as an alternative to giving access to system catalogs? |
|
I've created #105 for adding constraints to the internal schema representation. |
No, I was thinking about exposing some form of processed schema in our API, for some clients to consume, let's discuss this at some point |
In response to this comment #103 (comment). Theup sql is made optional as it's almost always going to be a straight copy of the value from the more restrictive schema to the less restrictive one.
Implement the
drop_constraintoperation for dropping constraints defined on single columns.An example of the operation looks like:
{ "name": "23_drop_check_constraint", "operations": [ { "drop_constraint": { "table": "posts", "column": "title", "name": "title_length", "up": "title", "down": "(SELECT CASE WHEN length(title) <= 3 THEN LPAD(title, 4, '-') ELSE title END)" } } ] }for dropping a
CHECKconstraint. And like this for dropping aFOREIGN KEYconstraint:{ "name": "24_drop_foreign_key_constraint", "operations": [ { "drop_constraint": { "table": "posts", "column": "user_id", "name": "fk_users_id", "up": "user_id", "down": "(SELECT CASE WHEN EXISTS (SELECT 1 FROM users WHERE users.id = user_id) THEN user_id ELSE NULL END)" } } ] }The operation works very similarly to the inverse operation of adding
CHECKandFOREIGN KEYconstraints to a single column.Start:upanddownSQL. ThedownSQL needs to ensure that rows inserted into the new view that don't meet the constraint are converted into rows that do meet the constraint.CompleteRollbackImprovements
drop_constraintoperation requires that the column on which the constraint is defined is named in the migrationjsonfile. Ifpg-roll's internal schema representation knew about the constraints defined on a table it would be possible to delete constraints by constraint name only; the schema representation would know on which column the constraint was defined.pg-rollcurrently only allows for creatingCHECKandFOREIGN KEYconstraints on single columns; this limitation also applies to thedrop_constraintoperation.