Re: `Model.validate_unique` excluding partial unique constraint
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 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 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 and remove the special handling in >> _validate_unique as well. >> >> I wonder if we'll want to add a Constraint(invalid_message) argument to >> allow for localized error messages to be raised on violation like we do >> with validators? >> >> Simon >> >> [0] https://github.com/django/django/pull/14494/ >> >> Le jeudi 24 juin 2021 à 08:25:21 UTC-4, gaga...@gmail.com a écrit : >> >>> 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 à 16:43:36 UTC+2, charettes a écrit : >>> > 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 : >
Re: include_block template tag
Hi Pierre,
I have been silently watching your progress with great enthusiasm. This
limitation of the DTL has been a thorn in my side for years. Are you able
to share any updates about your progress?
Cheers
Kye
On Friday, April 23, 2021 at 3:00:50 PM UTC+8 Pierre Vanliefland wrote:
> Hi Carlton,
>
> That would make sense. I'll keep testing/playing with it for the next few
> days, and will package it afterward.
>
> Kind regards,
>
> Pierre
>
> On Friday, April 23, 2021 at 6:19:34 AM UTC+2 carlton...@gmail.com wrote:
>
>> Hi Pierre.
>>
>> If you were to bundle it in a package and put in on PyPI, that would
>> allow others to easily experiment and feedback too.
>>
>> Kind regards, Carlton
>>
>> On Thu, 22 Apr 2021 at 21:33, Pierre Vanliefland
>> wrote:
>>
>>> Thanks Jure! In the meantime, I have started testing my code extensively
>>> and spotted a few problems, mostly linked to the usage of block nodes
>>> within {% embed %}.
>>>
>>> I have decide to use a new tag, {% slot %}, with a much simpler
>>> implementation and it seems to work just fine. I have updated the gist
>>>
>>> accordingly. I also have ditched the idea of reusing existing Django code
>>> (it was messy and confusing) but I have commented the code sections that
>>> are 100% identical to existing Django code, they could one day be
>>> refactored into helper methods / abstract classes.
>>>
>>> I plan to test this and release it in a production project over the next
>>> few weeks, I'll share my findings here after that.
>>>
>>> Kind regards,
>>>
>>> Pierre
>>>
>>> On Monday, April 19, 2021 at 11:16:08 AM UTC+2 jure.er...@gmail.com
>>> wrote:
>>>
Hi Pierre,
I like your solution very much: implements what needs to be
implemented, rationalises it very well and also adds all the other
bits'n'pieces required for a proper PR.
I really hope this gets accepted, it was a huge thorn in our butts
until we implemented it. Now we're (ab)using it everywhere.
LP,
Jure
On 17. 04. 21 10:23, Pierre Vanliefland wrote:
>>> Hi Carlton,
Thanks for replying so quickly. It's definitely been an itch for me, as
check the docs and Stack Overflow every year to check if this has been
implemented!
I've completed the Gist with an "include/extends" example, but I
haven't done the same for inclusion tags: as far as I know, an inclusion
tag has a single, fixed template, which would require you to create one
inclusion tag by component in your "design system", which would be even
more cumbersome. And it would not allow you to override multiple block
contents with arbitrary HTML, which is the goal here.
I plan to use my own implementation more extensively in the coming
weeks to check its robustness, but I would be super happy to propose a PR
if you find it interesting.
At the moment, it's not a big pain point for me, as I can use my custom
tag, but I agree with the feeling of Carl above: while useful, it's a
small
feature and I'm afraid users won't be attracted by a third-party plugin
for
50 lines of code...
I was wondering why I was feeling like this is a missing piece, and I
remembered this morning: I used this feature a lot when I was using Twig (
https://twig.symfony.com/doc/3.x/tags/embed.html).
It was super useful, especially when working on a web application (vs
website), where you have a lot of similar sections and widgets, and I've
been missing it a lot over the years.
Have a nice day!
Pierre
On Saturday, April 17, 2021 at 5:44:05 AM UTC+2 carlton...@gmail.com
wrote:
> Hi Pierre,
>
> No problem at all! There’s some itch that folks have here so all for
> the good discussing it.
>
> Thanks for your work on the gist it looks good. I just glanced at it
> now, and need to sit down longer but, can I ask you to add a “What’s
> wrong
> with the current tools” section to text? i.e. How would it look using
> include or a custom inclusion tag, and so why would a new tag be better?
> I
> think that would be helpful. (Make sense?)
>
> Kind Regards,
>
> Carlton
>
>
> On 16 Apr 2021, at 23:03, Pierre Vanliefland
> wrote:
>
> Hello! First, sorry if it is not appropriate to bring back this thread
> from the grave, but I spent some time on finding a solution for this and
> came up with an implementation that:
>
>1. Needs very little code
>2. Re-uses the existing code for the extends and include tags
>
> I have written a Gist that contain the full code (including text) and
> a bit of context:
> https://gist.github.com/pvanliefland/bb676a906b900c7e29e46b474038a6ca
>
> Do
