So am I right that the example model with deleted_at will not be validated by ModelForm as deleted_at will never be included in it?
I tried implementing ExclusionConstraint.validate (https://github.com/Gagaro/django/commit/558f33f574838b21cc9bf58a825ef337e7b1d0b2) but I had to use RawSQL as I didn't find another way to use the operator. It works great when running the query alone but: I don't like using raw SQL when there is a better way to do it (is there?). And it doesn't work when used in the Exists as the table is aliased and the raw SQL is not. Do you have any idea how to fix/improve that? Thanks again! Le lundi 21 juin 2021 à 18:00:03 UTC+2, charettes a écrit : > That's looking great :) > > 1. Yes and that's expected. If a form/serializer doesn't provide some > fields included in the constraint the database client side of the > validation can't do much about it. It might result in an integrity error > but that's a misuse of the API. I guess a check/runtime warning could be > emitted when creating model forms/serializers that don't fully cover > constraints define on attached models but that's already an issue with the > existing validate_unique logic. > 2. I guess it could be surfaced in Q.check and expected to be caught > Constraint.validate. Whichever layer performs the field exclusion should be > responsible for handling the FieldError. > 3. Yep definitely something we can bring to this list once we're satisfied > with the API. > 4. I guess we could yes! That makes me think we'll also want to implement > it for ExclusionConstraint if you're up for it! > > Simon > > Le lundi 21 juin 2021 à 08:54:59 UTC-4, gaga...@gmail.com a écrit : > >> I tried my hand at implementing Q.check() ( >> https://github.com/Gagaro/django/tree/ticket-30581). >> >> A few things: >> >> 1/ Is the exclude parameter there because of Model.validate_unique >> signature? Conditional UniqueConstraint might not work in those cases if a >> field use in a the condition is not in the form for example. >> 2/ Shouldn't we let the FieldError raising in Q.check() instead of >> returning None? Or raise another (new one?) exception? >> 3/ I'm not so sure anymore about the check name being better than >> matches. We might need more inputs on that one :). >> 4/ Should we raise NotImplementedError in BaseConstraint.validate? >> >> Thanks for your inputs. >> Le mercredi 16 juin 2021 à 17:08:24 UTC+2, Gaga Ro a écrit : >> >>> > yeah didn't want to step on your toes but I got very excited about >>> trying it out 😅 >>> >>> Don't worry about that, it's a good thing this motivated you enough to >>> advance on this topic. >>> >>> > I have a slight preference for the second option as it seems like it >>> could be used in other context than constraints[0] but I'm curious about >>> your thoughts? >>> >>> Yes I agree that this should be independent from models. There is no >>> reason to tie it to them, and if we want to do it anyway, it would be >>> trivial to do using the new method. Or maybe we could have both we >>> different named parameters and change the behaviour deping on those. >>> >>> > Looking at [0] in more details I also feel like matches() could be a >>> better name than check(). >>> >>> It should be obvious that the method return a boolean, matches sounds >>> like that it could returns a list of the matches to me. >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4bd947bb-d726-429b-8e02-4cf89809292bn%40googlegroups.com.
