Pull request created: https://github.com/django/django/pull/14625
Le lundi 12 juillet 2021 à 02:31:02 UTC+2, charettes a écrit :
> Awesome, thanks for your continued efforts on this!
>
> Le samedi 10 juillet 2021 à 14:41:05 UTC-4, gaga...@gmail.com a écrit :
>
>> No problem. The lookup PR has bee
Awesome, thanks for your continued efforts on this!
Le samedi 10 juillet 2021 à 14:41:05 UTC-4, gaga...@gmail.com a écrit :
> No problem. The lookup PR has been merged, I'll work on our PR monday.
>
> I'm all up for the invalid message, it will be shown to the end user after
> all.
>
> Le mercre
No problem. The lookup PR has been merged, I'll work on our PR monday.
I'm all up for the invalid message, it will be shown to the end user after
all.
Le mercredi 7 juillet 2021 à 20:53:23 UTC+2, charettes a écrit :
> Just a small note that I didn't forget about this thread but I was waiting
>
Just a small note that I didn't forget about this thread but I was waiting
for lookup annotation support to land before focusing on it[0].
I guess you could go ahead and create a PR once it lands.
I assume we'll want to have Model.full_clean take advantage of this new
Constraint.validate method
I took a bit of time to try with the new lookups and it looks much better!
Also it actually works now :).
Is the code ready for a PR? Or should I add the documentation / more tests
before?
https://github.com/Gagaro/django/commit/cfd10066359c175179ae937a287eb9f0240354f1
Le mardi 22 juin 2021 à
> 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
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
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 warnin
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
> 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.
yeah didn't want to step on your toes but I got very excited about trying
it out 😅
> Should we still add Q.check() (which will be as you said before), then
refactor BaseConstraint.validate() to use it?
I think it would still be worth doing to
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
I meant 1. in my previous email where sql.Query.model is allowed to be
None. The tests happen to pass on SQLite, MySQL, and Postgres.
Le mardi 15 juin 2021 à 20:02:28 UTC-4, charettes a écrit :
> FWIW I thought I'd give a timeboxed shot at 2. to make sure I don't send
> you towards a deep rabbi
FWIW I thought I'd give a timeboxed shot at 2. to make sure I don't send
you towards a deep rabbit hole and it seems pretty straightforward!
https://github.com/django/django/compare/main...charettes:query-empty-model
Le lundi 14 juin 2021 à 03:09:35 UTC-4, gaga...@gmail.com a écrit :
> Thanks,
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
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 Expression which is
being worked on[0].
Ideally Q would also be made a subclass of Expression but that's likely a
big can of worms so I'd focus on implementing it for Q
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
Hello there,
Partial unique constraints are currently not supported during validation
for reasons described in this ticket[0].
For example (inspired by this Github comment[1]), if you define the
following model
class Article(models.Model):
slug = models.CharField(max_length=100)
delete
18 matches
Mail list logo
