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/c74725c3-8b6d-4f55-b06c-8d202409d958n%40googlegroups.com.
