Re: Recognising Contributions

[Carlton Gibson]

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 post (or another page) to include a long list of names of 
> everyone who contributeted a commit in that release. I think it's fine if 
> this is long, can probably use Simon W's GitHub-to-sqlite repo for this so 
> it is sustainable. [3]
>
> - For the headline features make a series of Twitter posts highlighting 
> them and acknowledge contributors. I'm thinking something along the lines 
> of what Adam Johnson did for the 3.2 release but include names & thank 
> yous. 
>
> - A rust style thanks page [4] (but **not** the all time list, I don't 
> think that's helpful and it's on GitHub anyway).
>
> - A go style contributor summit. (I don't think this is feasible, even 
> remotely. But I'll put it out there!). A slight variation on this could be 
> folk who have contributed could apply for different coloured conference 
> passes/lanyards.  [5]
>
> Kind Regards
>
> David
>
> [1]https://docs.python.org/3/whatsnew/3.8.html
> [2]https://www.djangoproject.com/weblog/2021/apr/06/django-32-released/
> [3]https://github.com/dogsheep/github-to-sqlite
> [4]https://thanks.rust-lang.org/
> [5]https://blog.golang.org/contributors-summit-2019
>

-- 
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/0174cb33-44e3-48f4-80dc-27b8f9fb8cb4n%40googlegroups.com.

Lack of validation at the object level.

[Михаил Итпрогер]

Hello, I am currently developing a reusable application using the Django framework.It just so happens that the instances of the models of this application will most often be created inside the code, and not in the forms.I've created validators for fields that only work in forms, but I would like to reuse them for creating/updating objects as well.The Django documentation says that validation only occurs on forms, but it is not written for what reason.I have tried many solutions to deal with this problem, but they all have a significant drawback - when creating an instance from a form, the validation happens twice. For example, with __setattr__():  once when the concstruct_instance() is called, the second time when full_clean().With save(): first full_clean(), and then my validation in save().I'm really interested in why the opportunity to validate everything at the object level was missed, because when creating objects outside the forms, you can enter any values ​​into the fields that contradict the restrictions. I could solve this problem, which would require small changes in the validation logic, but first I need to consult with you. Besides, maybe you can tell me an alternative solution.



-- 
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/E619D0E2-3B55-478F-895B-0F59848BAFA6%40hxcore.ol.

Re: Ability to annotate instances with querysets: reconsidering 30653

[Alexander Hill]

Hi Chris,

Without wanting to preclude discussion of this kind of functionality ending
up in Django itself, which I think would be great - I created
https://github.com/alexhill/django-relativity to meet this kind of need.

In your example, it would look a like this:

from relativity import Relationship, L

class A(models.Model):
...
b = models.ForeignKey(B)
c = models.ForeignKey(C)
d = Relationship(D, predicate=Q(a_id=L("a_id"), b_id=L("b_id"))

Now the field `d` is available on all instances of A, in ORM query syntax,
etc. As far as possible, it should work like a native Django relation.

The predicate is an arbitrary Q against the related model which can include
L objects, which refer to fields in the L for local model.

Let me know if this helps!

Cheers,
Alex

On Tue, Jun 29, 2021 at 11:14 PM Chris Le Sueur 
wrote:

> Hi all,
>
> In https://code.djangoproject.com/ticket/30653 a feature request was made
> to support annotating instances with an entire queryset. This was closed
> wontfix because you can do this with the prefetch_related mechanism.
>
> However, prefetch_related is very limited due to the design intention to
> support prefetching relationships defined in the ORM. My use case is to
> annotate each instance fetched in a queryset with a related queryset, where
> which objects are annotated depends on two fields of the original instance.
> Consider models A, B, C and D, where both A and D have foreign keys to both
> B and C, and you want to annotate a queryset of As with a collection of Ds
> which share the same pair of related B and C. (This is exactly the use case
> I have in mind, but of course it could be quite general.)
>
> Prefetch objects cannot be used because, firstly, a Prefetch on b__d_set
> (for example) will annotate the B models: there is no way to collect the D
> instances onto the A models; and secondly because there is no way to filter
> or join on the second field.
>
> prefetch_related is making some assumptions about the correct way to
> perform queries because of what it's there to do; a complete method for
> annotating querysets onto things would perhaps not want to query the
> related table via a "WHERE pk IN (...)" clause but instead query the root
> table's pk and JOIN on the subsequent tables - in the above scenario this
> would be very simple (... JOIN d ON (a.b_id = d.b_id AND a.c_id = d.c_id)).
> This avoids having to faff around getting ids for all the intermediate
> models in python and pass them back to the database (though presumably
> there's a reason for doing that in prefetch_related; maybe it would make
> sense here too.)
>
> The big issue for me is that there is not a good workaround for this at
> the moment. Suppose you frequently need access to things of this type (and
> need the performance gained by querying everything in one go) then you are
> forever querying tables directly and assembling dictionaries - instead of
> using the ORM to do this for you. If frequently need to do this for *the
> same* query, you can't really do it in a custom queryset without overriding
> _fetch_all, assembling the dictionary there and gluing collections onto
> instances there, which doesn't feel like a good thing to do.
>
> So I would suggest reopening the linked issue!
>
> Chris
>
> --
> 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/2353e3b5-f4cf-48f2-b647-9f400c05c571n%40googlegroups.com
> 
> .
>

-- 
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/CA%2BKBOKwBd0n7N%2BqRJhmy%3DWpt8dVFxS2PGRi%2BgRUdJ%2B-pdU3Jvw%40mail.gmail.com.

Re: Lack of validation at the object level.

['Adam Johnson' via Django developers (Contributions to Django itself)]

What validation do you need? Much can be done in the database with
constraints, especially check constraints.

On Wed, 30 Jun 2021 at 08:05, Михаил Итпрогер 
wrote:

> Hello, I am currently developing a reusable application using the Django
> framework.
>
> It just so happens that the instances of the models of this application
> will most often be created inside the code, and not in the forms.
> I've created validators for fields that only work in forms, but I would
> like to reuse them for creating/updating objects as well.
> The Django documentation says that validation only occurs on forms, but it
> is not written for what reason.
>
> I have tried many solutions to deal with this problem, but they all have a
> significant drawback - when creating an instance from a form, the
> validation happens twice.
>
> For example, with __setattr__():  once when the concstruct_instance() is
> called, the second time when full_clean().
>
> With save(): first full_clean(), and then my validation in save().
> I'm really interested in why the opportunity to validate everything at the
> object level was missed, because when creating objects outside the forms,
> you can enter any values ​​into the fields that contradict the
> restrictions.
>
> I could solve this problem, which would require small changes in the
> validation logic, but first I need to consult with you.
>
> Besides, maybe you can tell me an alternative solution.
>
> --
> 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/E619D0E2-3B55-478F-895B-0F59848BAFA6%40hxcore.ol
> 
> .
>

-- 
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/CAMyDDM30TzCLFMsktSLEnZjUhr6f4FsF7eg%3DpzcFqmSLyO0sfA%40mail.gmail.com.

Re: Lack of validation at the object level.

['Adam Johnson' via Django developers (Contributions to Django itself)]

"Unique restriction will be ignored" - this is not the case. Uniqueness is
enforced by the database, so as long as your migrations have been built and
run correctly, the database will error when trying to insert a duplicate
unique value. If you're finding that you can create duplicates on unique
fields, check your database setup.

For the case of checking whether a string contains a certain character, or
matches a format, it's possible to enforce in the database with a check
constraint. I've written several blog posts on the topic:
https://duckduckgo.com/?sites=adamj.eu&q=check+constraints&ia=web . None
exactly align with such string validation, but if you understand the
concepts you should be able to figure it out. Admittedly it's more
complicated than writing a validator function.

On Wed, 30 Jun 2021 at 16:00, Args Kwargs  wrote:

> Here's what I mean:
>
> ср, 30 июн. 2021 г. в 16:45, 'Adam Johnson' via Django developers
> (Contributions to Django itself) :
>
>> What validation do you need? Much can be done in the database with
>> constraints, especially check constraints.
>>
>> On Wed, 30 Jun 2021 at 08:05, Михаил Итпрогер 
>> wrote:
>>
>>> Hello, I am currently developing a reusable application using the Django
>>> framework.
>>>
>>> It just so happens that the instances of the models of this application
>>> will most often be created inside the code, and not in the forms.
>>> I've created validators for fields that only work in forms, but I would
>>> like to reuse them for creating/updating objects as well.
>>> The Django documentation says that validation only occurs on forms, but
>>> it is not written for what reason.
>>>
>>> I have tried many solutions to deal with this problem, but they all have
>>> a significant drawback - when creating an instance from a form, the
>>> validation happens twice.
>>>
>>> For example, with __setattr__():  once when the concstruct_instance()
>>> is called, the second time when full_clean().
>>>
>>> With save(): first full_clean(), and then my validation in save().
>>> I'm really interested in why the opportunity to validate everything at
>>> the object level was missed, because when creating objects outside the
>>> forms, you can enter any values ​​into the fields that contradict the
>>> restrictions.
>>>
>>> I could solve this problem, which would require small changes in the
>>> validation logic, but first I need to consult with you.
>>>
>>> Besides, maybe you can tell me an alternative solution.
>>>
>>> --
>>> 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/E619D0E2-3B55-478F-895B-0F59848BAFA6%40hxcore.ol
>>> 
>>> .
>>>
>> --
>> 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/CAMyDDM30TzCLFMsktSLEnZjUhr6f4FsF7eg%3DpzcFqmSLyO0sfA%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CANvv8_9YHZ2_e0UrfG8bzWUZkvm2e5N0L76RuS2X_bDtTF%2BK5Q%40mail.gmail.com
> 
> .
>

-- 
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/CAMyDDM0L%3DUrajOp04YdrKLjMKw_RsgiiLioUXExr0a%3DT-JJyyw%40mail.gmail.com.

Re: Lack of validation at the object level.

[Args Kwargs]

Thank you so much.

ср, 30 июн. 2021 г. в 18:43, 'Adam Johnson' via Django developers
(Contributions to Django itself) :

> "Unique restriction will be ignored" - this is not the case. Uniqueness is
> enforced by the database, so as long as your migrations have been built and
> run correctly, the database will error when trying to insert a duplicate
> unique value. If you're finding that you can create duplicates on unique
> fields, check your database setup.
>
> For the case of checking whether a string contains a certain character, or
> matches a format, it's possible to enforce in the database with a check
> constraint. I've written several blog posts on the topic:
> https://duckduckgo.com/?sites=adamj.eu&q=check+constraints&ia=web . None
> exactly align with such string validation, but if you understand the
> concepts you should be able to figure it out. Admittedly it's more
> complicated than writing a validator function.
>
> On Wed, 30 Jun 2021 at 16:00, Args Kwargs  wrote:
>
>> Here's what I mean:
>>
>> ср, 30 июн. 2021 г. в 16:45, 'Adam Johnson' via Django developers
>> (Contributions to Django itself) :
>>
>>> What validation do you need? Much can be done in the database with
>>> constraints, especially check constraints.
>>>
>>> On Wed, 30 Jun 2021 at 08:05, Михаил Итпрогер 
>>> wrote:
>>>
 Hello, I am currently developing a reusable application using the
 Django framework.

 It just so happens that the instances of the models of this application
 will most often be created inside the code, and not in the forms.
 I've created validators for fields that only work in forms, but I would
 like to reuse them for creating/updating objects as well.
 The Django documentation says that validation only occurs on forms, but
 it is not written for what reason.

 I have tried many solutions to deal with this problem, but they all
 have a significant drawback - when creating an instance from a form, the
 validation happens twice.

 For example, with __setattr__():  once when the concstruct_instance()
 is called, the second time when full_clean().

 With save(): first full_clean(), and then my validation in save().
 I'm really interested in why the opportunity to validate everything at
 the object level was missed, because when creating objects outside the
 forms, you can enter any values ​​into the fields that contradict the
 restrictions.

 I could solve this problem, which would require small changes in the
 validation logic, but first I need to consult with you.

 Besides, maybe you can tell me an alternative solution.

 --
 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/E619D0E2-3B55-478F-895B-0F59848BAFA6%40hxcore.ol
 
 .

>>> --
>>> 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/CAMyDDM30TzCLFMsktSLEnZjUhr6f4FsF7eg%3DpzcFqmSLyO0sfA%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> 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/CANvv8_9YHZ2_e0UrfG8bzWUZkvm2e5N0L76RuS2X_bDtTF%2BK5Q%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAMyDDM0L%3DUrajOp04YdrKLjMKw_RsgiiLioUXExr0a%3DT-JJyyw%40mail.gmail.com
> 

Re: Fellow Reports - June 2021

[Mariusz Felisiak]

Week ending June 27, 2021

*Triaged: *
   https://code.djangoproject.com/ticket/32856 - Django 2.2 not compatible 
with psycopg 2.9 (wontfix) 
   https://code.djangoproject.com/ticket/32862 - Order By in Postgres When 
Using Annotations Causes Ambiguous Field Name (needsinfo) 
   https://code.djangoproject.com/ticket/32867 - django admin - protect 
againt mutual edit of same object (duplicate) 
   https://code.djangoproject.com/ticket/32659 - Autocomplete field: The 
results could not be loaded. (needsinfo) 
   https://code.djangoproject.com/ticket/32865 - manage.py makemigrations 
command gives an unexpected issue in check_consistent_history. (invalid) 
   https://code.djangoproject.com/ticket/32869 - Bug while migrating a 
OneToOneField to ForeignKey on PostgreSQL. (worksforme) 
   https://code.djangoproject.com/ticket/32870 - Added message when user 
mispells 'urlpatterns' in some 'urls' module (accepted) 
   https://code.djangoproject.com/ticket/32868 - Add system check or 
warning for model fields shadowing methods / other attributes (wontfix) 
   https://code.djangoproject.com/ticket/32875 - Which is prefered for 
`default_related_name`? (invalid) 
   https://code.djangoproject.com/ticket/32876 - The parametered `all` is 
not preserved after save object in django admin. (invalid) 
   https://code.djangoproject.com/ticket/32877 - request.POST sending array 
(invalid) 
   https://code.djangoproject.com/ticket/32878 - Seems that browsing 
releases in Django Project website interchanged "Prev" and "Next" links. 
(invalid) 
   https://code.djangoproject.com/ticket/32880 - Improve logging 
documentation (accepted) 
   https://code.djangoproject.com/ticket/32881 - Inconsistent user models 
in contrib.auth.forms. (duplicate) 
   https://code.djangoproject.com/ticket/25265 - DB Backend cannot specify 
query class. (someday/maybe) 
   https://code.djangoproject.com/ticket/24096 - GROUP BY on oracle fails 
with TextField and BinaryField (duplicate) 
   https://code.djangoproject.com/ticket/25456 - Make GenericIPAddressField 
normalize IPv4 addresses (fixed) 

*Reviewed/committed: *
   https://github.com/django/django/pull/14535 - Fixed #32859 -- Simplified 
compress_string() by using gzip.compress(). 
   https://github.com/django/djangoproject.com/pull/1100 - Made docs 
permalinks focusable to improve accessibility. 
   https://github.com/django/django/pull/14537 - Fixed #32860 -- Made docs 
permalinks focusable to improve accessibility. 
   https://github.com/django/django/pull/14536 - Fixed #32858 -- Fixed 
ExclusionConstraint crash with index transforms in expressions. 
   https://github.com/django/django/pull/14524 - Fixed #32842 -- Refactored 
out CsrfViewMiddleware._check_token(). 
   https://github.com/django/django/pull/14453 - Fixed #32870 -- Improved 
error message when URLconf is empty. 
   https://github.com/django/django/pull/14389 - Refs #32338 -- Removed 
'for ="..."' from RadioSelect's . 
   https://github.com/django/django/pull/14549 - Fixed #32863 -- Skipped 
system check for specifying type of auto-created primary keys on models 
with invalid app_label. 
   https://github.com/django/django/pull/14531 - Refs #24121 -- Added 
__repr__() to StreamingHttpResponse and subclasses. 
   https://github.com/django/django/pull/14542 - Removed options parameter 
from djangoAdminSelect2. 
   https://github.com/django/django/pull/14518 - Fixed #32817 -- Added the 
token source to CsrfViewMiddleware's bad token error messages. 
   https://github.com/django/django/pull/14368 - Fixed #32727 -- Allowed 
spaces before time zone offset in parse_datetime(). 
   https://github.com/django/django/pull/14555 - Refs #32880 -- Improved 
some headings and text in logging topic. 
   https://github.com/django/django/pull/14545 - Refs #32508 -- Raised 
ImproperlyConfigured/TypeError instead of using "assert" in various code. 
   https://github.com/django/django/pull/14557 - Refs #32880 -- Improved 
some how-to notes in logging topic. 

*Authored: *
   https://github.com/django/django/pull/14547 - [2.2.x] Refs #32856 -- 
Doc'd that psycopg2 < 2.9 is required.

Best,
Mariusz

-- 
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/88ca0ccc-4a86-40fb-b26f-81bb1c44df19n%40googlegroups.com.