Re: `Model.validate_unique` excluding partial unique constraint

[charettes]

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 :
>
>> > 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 

Re: Recognising Contributions

[Tom Carrick]

This is something I've been thinking about a bit as well.

Mostly I think adding authors to the release notes is probably the best
bang for buck in terms of recognition. This is what I was mostly thinking
about myself. The release notes are (I believe) very widely read,
especially in comparison with anything on GitHub.

The other suggestions are, I think, good and worthwhile, but probably not
as impactful.

I am interested / curious about your last point. I think adding some
recognition to in person events might be nice, but I'm not sure what it
would look like in practice.

Tom

On Mon, 5 Jul 2021 at 17:38, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> I'm all for exposing names in more places.
>
> Linking through to PR's from the release notes would also be useful for
> "pulling back the curtain" and making Django's code a bit less magical.
> Plus it could help the workflow for current contributors.
>
> On Mon, 5 Jul 2021 at 16:07, Tom Forbes  wrote:
>
>> Perhaps we could do this as part of a Sphinx plugin? Right now each entry
>> in the release notes is only implicitly tied to the pull request that adds
>> it.
>>
>> If we could add some kind of pull request ID marker to the release note
>> entries we could create an inline link to the PR (which might be very
>> useful by itself) as well as using it derive a list of contributors for
>> each release.
>>
>> Tom
>>
>> On Wed, 30 Jun 2021 at 09:16, Carlton Gibson 
>> wrote:
>>
>>> Hi David,
>>>
>>> Thanks for this. Yes.
>>>
>>> Let's assume the 2020-2021 time filter is in place.
>>>
>>> Mariusz recently picked up James' PR to add the list of Core
>>> Contributors (back) to the website, which is/was part of the DEP 10
>>> governance changes.
>>> https://github.com/django/djangoproject.com/pull/1099
>>>
>>> The hope is that the DSF Board will approve that in their next meeting,
>>> and we can get it live. With hindsight we perhaps could have moved quicker
>>> but, the idea was to move on from there to recognise current and new
>>> contributors on a more ongoing basis too.
>>>
>>> So... my hope was to probably do something per-major release — so 3.2,
>>> 4.0, 4.1, etc. (Maybe we could do it every month but...)
>>>
>>> * Who were the contributors?
>>> * Who were the new contributors?(Special callout)
>>> * Who was on the Triage and Review team? ('cause it ain't just code)
>>> * And, can we identify other folks to call out...? (T&R team was an
>>> attempt to capture participation here.)
>>>
>>> I think Simon's github-to-sqlite tool is a good candidate.
>>> Some others I've collected whilst this has been bubbling on the
>>> low-ring:
>>>
>>> * Katie McLaughlin provided some git log pointers
>>> https://glasnt.com/blog/script-o-hatrack/
>>> * See also https://github.com/LABHR/octohatrack
>>> * GitHub built this based on Simon's ideas:
>>> https://octo.github.com/projects/flat-data
>>> * "A git query language" https://github.com/filhodanuvem/gitql
>>> * "git quick stats" https://github.com/arzzen/git-quick-stats
>>>
>>> I think there's plenty of tooling there to show how to get the info we
>>> want.
>>> At a guess it's a couple of evenings exploring, and then pulling it into
>>> a report.
>>>
>>> I think if we were to do something along these lines, starting a new
>>> tradition, for Django 4.0 in December, that would be really great.
>>>
>>> I'm not sure as yet on the exact format to present all that.
>>> The blog post for the _Final_ versions could say more without too much
>>> difficulty.
>>> (e.g.
>>> https://www.djangoproject.com/weblog/2021/apr/06/django-32-released/ )
>>>
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>>
>>>
>>>
>>> On Tuesday, 29 June 2021 at 21:35:16 UTC+2 smi...@gmail.com wrote:
>>>
 Hi all,

 I've had this sat in my drafts for a while. Rather than let it sit on
 the shelf any longer I thought it better to share.

 I've been thinking about recognising contributions recently. The main
 issue with the notes here is that it focuses on code rather than
 contributions to the wider Django ecosystem. However, if there are
 improvements that we could make here I think we should explore those, and
 maybe some of them could be used more widely.

 Here are a few ideas of how contributions could be recognise following
 a peer review of other projects. Some are better than others, some are
 easier to implement than others. Hopefully something to prompt some
 discussion. What do folk think? How would you feel if you were recognised
 in one of these ways?

 - Add Python style `contributed by` in the release notes. I'm not so
 sure about adding the ticket number (in fact I think I saw Nick Pope point
 to something today that says we don't ref tickets?). [1]

 - For the headline features add names to the blog post [2]. Could also
 add link to their blog / website /Twitter (less sure about this second
 part).

 - The blog