ile since I looked at CTEs, so I might be missing something.
>
>
>
> I would hate to see us create an entirely separate API for CTEs.
>
>
>
>
>
> *From:* django-d...@googlegroups.com *On
> Behalf Of *Gaga Ro
> *Sent:* Tuesday, May 10, 2022 9:01 AM
Hello everyone,
I'm often using django-cte and I'd be thrilled to have CTE in the core.
If I'm not mistaken, the only DB currently supported by Django and not
having CTE support is MySQL 5.7 (with an end of life in October 2023). I
don't know if Django 4.2 will support it, but it should be drop
27;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 ex
t;>>> 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
>>>>>
>>>>&
>> 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 rais
ore 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 :
>>
&g
entedError 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 mo
> 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 constrai
It looks like you went even further than that :D.
Should we still add Q.check() (which will be as you said before), then
refactor BaseConstraint.validate() to use it?
Le mercredi 16 juin 2021 à 02:04:31 UTC+2, charettes a écrit :
> I meant 1. in my previous email where sql.Query.model is allowe
Thanks, it clears things a lot.
I'll try my hand at it when I'll have some more time available.
Le jeudi 10 juin 2021 à 06:00:17 UTC+2, charettes a écrit :
> Alright so here's for a few hints about I believe things should be done.
>
> First things first Lookup must be made a subclass of Expressi
Thanks for the thorough answer. I also realize now that it worked in my app
only because of another side effect when my instance was saved..
I started to take a look at the ORM part where the check method should be
implemented as I'm not used to it. Shouldn't .check() be implemented on Q
and no
Hi,
I changed several models from fields using `unique=True` to using
`UniqueConstraint` with a condition in the Meta.
As a side-effect, the uniqueness are no longer validated during cleaning of
a Form and an integrity error is raised. This is because partial unique
indexes are excluded :
http
12 matches
Mail list logo