Honour DEFERRABLE on all constraints in PostgreSQL #75
Conversation
|
@ilmari has mentioned that pg also has INITIALLY DEFERRED and INITIALLY IMMEDIATE I haven't dealt with that situation because the original code didn't; I consider this PR a bugfix, and that a new feature, hence out of scope, to my mind. Well, I didn't deal with that situation because I didn't consider it, but I still think it deserves its own feature request. |
| @@ -56,6 +56,7 @@ Object constructor. | |||
| match_type => 'full', # how to match | |||
| on_delete => 'cascade', # what to do on deletes | |||
| on_update => '', # what to do on updates | |||
| deferrable => 0, # whether to set DEFERRABLE, if supported by the database | |||
There was a problem hiding this comment.
@Altreus Ah I now understand. I thought you implemented the deferrable flag as an {extra} since it is supported by one and onky one highly non-standard engine. Hence why I was talking about sqlt_extra and was confused by how names etc applies in the other PR.
I really recommend moving this to extra like all other non-standard extension, e.g.: https://metacpan.org/pod/SQL::Translator::Producer::MySQL#Extra-attributes
Then the entire not on what is and isn't ignored in https://github.com/dbsrgits/dbix-class/pull/88/files#diff-14a995427a39511927479ae4ffbbb9c7R768 becomes moot.
@ilmari thoughts?
There was a problem hiding this comment.
deferrable constraints are part of the SQL standard, so I'm with @ilmari's original implementation here (sorry to revive a 6-year old thread, i'm just reviewing this to merge b/c I need it for $work)
|
@Altreus it is still on my radar, because it integrates with a part of DBIC I have postponed looking at it until I get the corresponding part in DBIC thought through. At this point there is nothing you need to do about it, ignore the coverage thing. Sorry for the delays, I am working as fast as I can. |
|
Thanks for the update. Let me know if I can help with further changes! |
Codecov Report
@@ Coverage Diff @@
## master #75 +/- ##
==========================================
+ Coverage 21.5% 21.53% +0.03%
==========================================
Files 71 71
Lines 19913 19917 +4
Branches 5728 5730 +2
==========================================
+ Hits 4282 4289 +7
Misses 14922 14922
+ Partials 709 706 -3
Continue to review full report at Codecov.
|
The docs quoted by the PostgreSQL provider say that all constraints can be deferrable.
https://metacpan.org/pod/SQL::Translator::Producer::PostgreSQL#PostgreSQL-Create-Table-Syntax
However, if we just shove DEFERRABLE on everything, most things will break, because a deferrable primary key cannot be used in someone else's foreign key.
After some discussion in #dbix-class we decided it would suffice to change the DEFERRABLE default so that it is true for foreign keys, but false otherwise. This mimics the existing behaviour, while still allowing for the new behaviour to be specified.
I've fixed the tests to allow for this change, but I've not extended them to look for it.