> 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.
I think the issue is that you're resolving before annotation/aliasing. If
#27021
landed you could actually create a Lookup instance to contain both the rhs
and lhs and just use that but in the mean time you're kind of stuck to
writing your own Expression subclass. Maybe we should just rebase the
branch on top of the current work of #27021[0] since it should land before
this work anyway?
Simon
[0] https://github.com/django/django/pull/14494
Le lundi 21 juin 2021 à 17:07:39 UTC-4, gaga...@gmail.com a écrit :
> 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/597069fa-9e74-4709-8b17-6404885fa05fn%40googlegroups.com.
