3.next - Fix unique constraints getting lost. #967
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using the first column of the constraints and foreign keys to index the rules array, constraints and foreign keys that share the same first column in the composite constraint will overwrite previously set rules. refs #957
ndm2
force-pushed
the
3.x-fix-unique-constraints-getting-lost
branch
from
aa4f075 to
07a460a
Compare
|
3.next does make sense for this and some other feature PRs |
ndm2
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using the first column of the constraints and foreign keys to index the rules array, constraints and foreign keys that share the same first column in the composite constraint will overwrite previously set rules.
Now that is kind of a breaking change for people that are using custom table templates and/or custom model commands, but I don't really see a good way to fix this in a backwards compatible manner without awkward workarounds that will eventually still have pitfalls. Maybe this should rather go in a not yet existent 3.next?
Ideally there would be support for multiple error fields, as setting the error on the first field only is kinda awkward. Any opinions on that?
refs #957