Re: [Django] #33208: Allow globally defining custom (i.e. with select_related) querysets for ModelChoiceFields/ForeignKeys

[Django]

#33208: Allow globally defining custom (i.e. with select_related) querysets for
ModelChoiceFields/ForeignKeys
---+--
 Reporter:  Matthijs Kooijman  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Also, there are both [https://www.youtube.com/watch?v=e52S1SjuUeM
 established ways of optimising this] and
 [https://docs.djangoproject.com/en/3.2/ref/forms/fields/#iterating-
 relationship-choices customising choice generation] (but these are topics
 for [https://forum.djangoproject.com/c/users/6/l/latest the Using category
 on the Forum] rather than here 🙂)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.15c7b47daefde2d342fbccf888062889%40djangoproject.com.

Re: [Django] #33208: Allow globally defining custom (i.e. with select_related) querysets for ModelChoiceFields/ForeignKeys

[Django]

#33208: Allow globally defining custom (i.e. with select_related) querysets for
ModelChoiceFields/ForeignKeys
---+--
 Reporter:  Matthijs Kooijman  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => contrib.admin


Comment:

 Thanks for the report, however I don't think a new hook is necessary you
 can use
 
[https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.autocomplete_fields
 ModelAdmin.autocomplete_fields] to avoid selecting all related instances
 to display in the dropdown, as documented:

 > ''"By default, the admin uses a select-box interface () for
 those fields. Sometimes you don’t want to incur the overhead of
 **selecting all the related instances** to display in the dropdown. The
 Select2 input looks similar to the default input but comes with a search
 feature that loads the options asynchronously. This is faster and more
 user-friendly if the related model has many instances."''

 For example:
 {{{#!python
 @admin.register(Book)
 class BookAdmin(admin.ModelAdmin):
 search_fields = ['name', 'author__name']

 # Register your models here.
 @admin.register(BookReview)
 class BookReviewAdmin(admin.ModelAdmin):
 autocomplete_fields = ['book']
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.ca1d5c071c157e45885b0e2913f2af58%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  Yuta Okamoto |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 I agree with Simon. As documented ''"Using add() on a relation that
 already exists won’t duplicate the relation,..."'' and in your case
 `member` and `company` are already related.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c65f31ede8f8c2641aeeaf0893c6d730%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  Yuta Okamoto |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I'll let others chime in but I think this is invalid.

 `ManyToManyField` was designed to allow only a single instance of the
 relationship it defines and not allow extra dimensions to be considered.
 In your case that means a single instance of the `Member <-> Company`
 many-to-many relationship can be tracked at a time and the `role`
 dimension is not taken into account at all.

 If you want to keep using `ManyToManyField` for this purpose you'll likely
 need to tweak your data model a bit

 e.g.

 {{{#!python
 class Company(models.Model):
 pass

 class Role(models.Model):
 company = models.ForeignKey(Company, related_name='roles')

 class Member(models.Model):
 roles = models.ManyToManyField(Role, related_name='members')

@property
def companies(self):
return Company.objects.filter(roles__members=self)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.64b9955b478ec36b32e2dce310ce3da7%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  Yuta Okamoto |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Yuta Okamoto:

Old description:

> I added the following `Company` and `Member` models, and `CompanyMember`
> as their intermediate table with a unique constraint including `role`
> field in addition to `through_fields`.
>
> {{{#!python
> from django.db import models
>
> class Company(models.Model):
> pass
>
> class Member(models.Model):
> companies = models.ManyToManyField(Company, through='CompanyMember',
> through_fields=('company', 'member'), related_name='members')
>
> class CompanyMember:
> company = models.ForeignKey(Company, on_delete=models.CASCADE)
> member = models.ForeignKey(Member, on_delete=models.CASCADE)
> role = models.SmallIntegerField()
>
> class Meta:
> constraints = [
> models.UniqueConstraint(fields=['company', 'member', 'role'],
> name='company_member_role'),
> ]
> }}}
>
> In this situation, `company.members.add()` silently fails to add existing
> member with different role specified via `through_defaults`.
>
> {{{#!python
> company = Company.objects.create()
> member = Member.objects.create()
>
> company.members.add(member, through_defaults={'role': 1})
> assert company.members.through.objects.all().count() == 1
>
> company.members.add(member, through_defaults={'role': 2})
> assert company.members.through.objects.all().count() == 2  # fails
> }}}
>
> We need to workaround by adding the relation to the intermediate table
> directly.
>
> {{{#!python
> company.members.through.objects.create(
> company.members.through(company=company, member=member, role=2)
> )
> }}}

New description:

 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 through_fields=('company', 'member'), related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` silently fails to add existing
 member with different role specified via `through_defaults`.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert company.members.through.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert company.members.through.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(company=company, member=member,
 role=2)
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e3b8bc794efb4974f75a9324ae6bb473%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  Yuta Okamoto |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Yuta Okamoto:

Old description:

> I added the following `Company` and `Member` models, and `CompanyMember`
> as their intermediate table with a unique constraint including `role`
> field in addition to `through_fields`.
>
> {{{#!python
> from django.db import models
>
> class Company(models.Model):
> pass
>
> class Member(models.Model):
> companies = models.ManyToManyField(Company, through='CompanyMember',
> related_name='members')
>
> class CompanyMember:
> company = models.ForeignKey(Company, on_delete=models.CASCADE)
> member = models.ForeignKey(Member, on_delete=models.CASCADE)
> role = models.SmallIntegerField()
>
> class Meta:
> constraints = [
> models.UniqueConstraint(fields=['company', 'member', 'role'],
> name='company_member_role'),
> ]
> }}}
>
> In this situation, `company.members.add()` silently fails to add existing
> member with different role specified via `through_defaults`.
>
> {{{#!python
> company = Company.objects.create()
> member = Member.objects.create()
>
> company.members.add(member, through_defaults={'role': 1})
> assert company.members.through.objects.all().count() == 1
>
> company.members.add(member, through_defaults={'role': 2})
> assert company.members.through.objects.all().count() == 2  # fails
> }}}
>
> We need to workaround by adding the relation to the intermediate table
> directly.
>
> {{{#!python
> company.members.through.objects.create(
> company.members.through(company=company, member=member, role=2)
> )
> }}}

New description:

 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 through_fields=('company', 'member'), related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` silently fails to add existing
 member with different role specified via `through_defaults`.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert company.members.through.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert company.members.through.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(
 company.members.through(company=company, member=member, role=2)
 )
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2bc13d9bc705656f5efd7c17634e23fa%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  Yuta Okamoto |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Yuta Okamoto:

Old description:

> I added the following `Company` and `Member` models, and `CompanyMember`
> as their intermediate table with a unique constraint including `role`
> field in addition to `through_fields`.
>
> {{{#!python
> from django.db import models
>
> class Company(models.Model):
> pass
>
> class Member(models.Model):
> companies = models.ManyToManyField(Company, through='CompanyMember',
> related_name='members')
>
> class CompanyMember:
> company = models.ForeignKey(Company, on_delete=models.CASCADE)
> member = models.ForeignKey(Member, on_delete=models.CASCADE)
> role = models.SmallIntegerField()
>
> class Meta:
> constraints = [
> models.UniqueConstraint(fields=['company', 'member', 'role'],
> name='company_member_role'),
> ]
> }}}
>
> In this situation, `company.members.add()` fails to add existing member
> with different role specified via `through_defaults`.
>
> {{{#!python
> company = Company.objects.create()
> member = Member.objects.create()
>
> company.members.add(member, through_defaults={'role': 1})
> assert company.members.through.objects.all().count() == 1
>
> company.members.add(member, through_defaults={'role': 2})
> assert company.members.through.objects.all().count() == 2  # fails
> }}}
>
> We need to workaround by adding the relation to the intermediate table
> directly.
>
> {{{#!python
> company.members.through.objects.create(
> company.members.through(company=company, member=member, role=2)
> )
> }}}

New description:

 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` silently fails to add existing
 member with different role specified via `through_defaults`.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert company.members.through.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert company.members.through.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(
 company.members.through(company=company, member=member, role=2)
 )
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5d6e79510422287fb4051e7c58a2809e%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  okapies  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by okapies:

Old description:

> I added the following `Company` and `Member` models, and `CompanyMember`
> as their intermediate table with a unique constraint including `role`
> field in addition to `through_fields`.
>
> {{{#!python
> from django.db import models
>
> class Company(models.Model):
> pass
>
> class Member(models.Model):
> companies = models.ManyToManyField(Company, through='CompanyMember',
> related_name='members')
>
> class CompanyMember:
> company = models.ForeignKey(Company, on_delete=models.CASCADE)
> member = models.ForeignKey(Member, on_delete=models.CASCADE)
> role = models.SmallIntegerField()
>
> class Meta:
> constraints = [
> models.UniqueConstraint(fields=['company', 'member', 'role'],
> name='company_member_role'),
> ]
> }}}
>
> In this situation, `company.members.add()` fails to add existing member
> with different role specified via `through_defaults`.
>
> {{{#!python
> company = Company.objects.create()
> member = Member.objects.create()
>
> company.members.add(member, through_defaults={'role': 1})
> assert Company.objects.all().count() == 1
>
> company.members.add(member, through_defaults={'role': 2})
> assert Company.objects.all().count() == 2  # fails
> }}}
>
> We need to workaround by adding the relation to the intermediate table
> directly.
>
> {{{#!python
> company.members.through.objects.create(
> company.members.through(company=company, member=member, role=2)
> )
> }}}

New description:

 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` fails to add existing member
 with different role specified via `through_defaults`.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert company.members.through.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert company.members.through.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(
 company.members.through(company=company, member=member, role=2)
 )
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.22d8f61097bb7ecd6cd45a735cc7e057%40djangoproject.com.

Re: [Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
 Reporter:  okapies  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by okapies:

Old description:

> I added the following `Company` and `Member` models, and `CompanyMember`
> as their intermediate table with a unique constraint including `role`
> field in addition to `through_fields`.
>
> {{{#!python
> from django.db import models
>
> class Company(models.Model):
> pass
>
> class Member(models.Model):
> companies = models.ManyToManyField(Company, through='CompanyMember',
> related_name='members')
>
> class CompanyMember:
> company = models.ForeignKey(Company, on_delete=models.CASCADE)
> member = models.ForeignKey(Member, on_delete=models.CASCADE)
> role = models.SmallIntegerField()
>
> class Meta:
> constraints = [
> models.UniqueConstraint(fields=['company', 'member', 'role'],
> name='company_member_role'),
> ]
> }}}
>
> In this situation, `company.members.add()` fails to add existing member
> with different role.
>
> {{{#!python
> company = Company.objects.create()
> member = Member.objects.create()
>
> company.members.add(member, through_defaults={'role': 1})
> assert Company.objects.all().count() == 1
>
> company.members.add(member, through_defaults={'role': 2})
> assert Company.objects.all().count() == 2  # fails
> }}}
>
> We need to workaround by adding the relation to the intermediate table
> directly.
>
> {{{#!python
> company.members.through.objects.create(
> company.members.through(company=company, member=member, role=2)
> )
> }}}

New description:

 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` fails to add existing member
 with different role specified via `through_defaults`.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert Company.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert Company.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(
 company.members.through(company=company, member=member, role=2)
 )
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ceda743680c0afde0dd468ec1ef95058%40djangoproject.com.

[Django] #33209: ManyToManyField.add() doesn't respect a unique constraint in intermediate table

[Django]

#33209: ManyToManyField.add() doesn't respect a unique constraint in 
intermediate
table
-+-
   Reporter:  okapies|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I added the following `Company` and `Member` models, and `CompanyMember`
 as their intermediate table with a unique constraint including `role`
 field in addition to `through_fields`.

 {{{#!python
 from django.db import models

 class Company(models.Model):
 pass

 class Member(models.Model):
 companies = models.ManyToManyField(Company, through='CompanyMember',
 related_name='members')

 class CompanyMember:
 company = models.ForeignKey(Company, on_delete=models.CASCADE)
 member = models.ForeignKey(Member, on_delete=models.CASCADE)
 role = models.SmallIntegerField()

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['company', 'member', 'role'],
 name='company_member_role'),
 ]
 }}}

 In this situation, `company.members.add()` fails to add existing member
 with different role.

 {{{#!python
 company = Company.objects.create()
 member = Member.objects.create()

 company.members.add(member, through_defaults={'role': 1})
 assert Company.objects.all().count() == 1

 company.members.add(member, through_defaults={'role': 2})
 assert Company.objects.all().count() == 2  # fails
 }}}

 We need to workaround by adding the relation to the intermediate table
 directly.

 {{{#!python
 company.members.through.objects.create(
 company.members.through(company=company, member=member, role=2)
 )
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.f6a5373de2aa39d4e99e1d890d36ccf5%40djangoproject.com.

Re: [Django] #22420: Postgresql connections not being dropped between tests?

[Django]

#22420: Postgresql connections not being dropped between tests?
---+--
 Reporter:  Matthew Fisher |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Peter Ashford):

 * cc: Peter Ashford (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.38531d3ec6257b5e8704af032fd64115%40djangoproject.com.

Re: [Django] #22420: Postgresql connections not being dropped between tests?

[Django]

#22420: Postgresql connections not being dropped between tests?
---+--
 Reporter:  Matthew Fisher |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.0
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Peter Ashford):

 I have the same issue. I am using a TransactionTestCase with multiple
 threads
 Postgres 12.8 (Ubuntu 12.8-0ubuntu0.20.04.1)
 Django 2.2.16.
 Nosetests test runner v1.3.7
 I'm not using __init__ in my test classes (as per last post on this bug)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.93f21e36eedd6223d893594a2fa4e25d%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`.

[Django]

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 You're right, sorry, I missed ''"... check the command’s source code for
 the **dest** argument passed to parser.add_argument()."''. In that case I
 would raise an error that passing `dest` with multiple arguments via
 `**options` is not supported.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.71e953b84abceade213336f0b74cccbf%40djangoproject.com.

Re: [Django] #29049: Add slicing notation to F expressions

[Django]

#29049: Add slicing notation to F expressions
-+-
 Reporter:  Matthew Pava |Owner:  David
 |  Smith
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  slice F  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Smith):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.12d95c9d7a2a9514a5d98ed96645a0a0%40djangoproject.com.

Re: [Django] #33205: call_command() fails when required mutually exclusive arguments use the same `dest`.

[Django]

#33205: call_command() fails when required mutually exclusive arguments use the
same `dest`.
-+-
 Reporter:  Peter Law|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  3.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hasan Ramezani):

 Replying to [comment:4 Mariusz Felisiak]:

 I am not sure about your second example:

 > * `management.call_command('pause', **{'for': '1'})` should work the
 same as calling `pause --for 1`

 Based on the documentation, it seems we have to pass `dest` as keyword
 argument name when we define `dest` for arguments.


 >Some command options have different names when using call_command()
 instead of django-admin or manage.py. For example, django-admin
 createsuperuser --no-input translates to call_command('createsuperuser',
 interactive=False). To find what keyword argument name to use for
 call_command(), check the command’s source code for the dest argument
 passed to parser.add_argument().


 Also,  when Django
 
[https://github.com/django/django/blob/e2f778d57947d168a875159e6df075255eea4bbc/django/core/management/__init__.py#L149
 adds required arguments in call command], it search for `dest` in options.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4e8ec98279d5ab890390e07b919671cd%40djangoproject.com.

Re: [Django] #27079: Refactor LiveServerPort tests to not make extra calls to setUpClass() and tearDownClass()

[Django]

#27079: Refactor LiveServerPort tests to not make extra calls to setUpClass() 
and
tearDownClass()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9dc9f99ac7e116470d94b69764d54e57%40djangoproject.com.

Re: [Django] #27079: Refactor LiveServerPort tests to not make extra calls to setUpClass() and tearDownClass()

[Django]

#27079: Refactor LiveServerPort tests to not make extra calls to setUpClass() 
and
tearDownClass()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15007 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f0996dc43f4bb9fe9e76def4c4f9149f%40djangoproject.com.

Re: [Django] #28821: Allow QuerySet.bulk_create() on multi-table inheritance when possible

[Django]

#28821: Allow QuerySet.bulk_create() on multi-table inheritance when possible
-+-
 Reporter:  Joey Wilhelm |Owner:  Jon
 |  Dufresne
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shai Berger):

 * cc: Shai Berger (added)


Comment:

 There's a naive implementation of a special case in the new broken-down-
 models library. Could be interesting to compare.
 https://github.com/Matific/broken-down-
 models/blob/main/bdmodels/models.py#L114 (actual line number may have
 changed by the time you read this, of course)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.46c640818e3faae4ac8ceaf5bba73678%40djangoproject.com.

[Django] #33208: Allow globally defining custom (i.e. with select_related) querysets for ModelChoiceFields/ForeignKeys

[Django]

#33208: Allow globally defining custom (i.e. with select_related) querysets for
ModelChoiceFields/ForeignKeys
-+
   Reporter:  Matthijs Kooijman  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Uncategorized  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 TL;DR: In cases where you have models with a foreignkey, a
 ModelChoiceField (e.g. using ModelAdmin), and a `__str__` method that uses
 a related field, a lot of queries might be duplicated. There does not
 currently seem to be a clean way to add select_related in the right place
 to fix this cleanly.

 e.g. consider something like this:

 {{{
 from django.db import models
 from django.contrib import admin

 class Author(models.Model):
 name = models.CharField(max_length=255)

 class Book(models.Model):
 name = models.CharField(max_length=255)
 author = models.ForeignKey(Author, on_delete=models.CASCADE)
 def __str__(self):
 return "{} by {}".format(self.name, self.author.name)

 class BookReview(models.Model):
 book = models.ForeignKey(Book, on_delete=models.CASCADE)
 rating = models.IntegerField()

 @admin.register(BookReview)
 class BookReviewAdmin(admin.ModelAdmin):
 pass
 }}}

 When showing the admin change view for a Review, I get a ton of queries
 when the ModelChoiceField tries to render all options for the `book`
 field. For each Book in the database, it calls `__str__`, which does a
 single query to retrieve `self.author.name`.

 The obvious fix for this would be to ensure that the ModelChoiceField
 queryset uses `select_related` to prefetch all data. I've found that this
 is possible by defining `formfield_for_foreignkey` on (in this case)
 `BookReviewAdmin`, e.g. something like:

 {{{
 def formfield_for_foreignkey(self, db_field, request, **kwargs):
 if db_field.name == "book":
 kwargs['queryset'] =
 Book.objects.all().select_related('author')
 return super().formfield_for_foreignkey(db_field, request,
 **kwargs)
 }}}

 This particular implementation has the downside that it bypasses the
 default queryset processing of ModelAdmin (currently only applying the
 ordering for the ModelAdmin registered for Book, if any). It would be
 nicer to override `ModelAdmin.get_field_queryset`, but that does not seem
 to be a public API.

 In any case, the bigger problem with this approach, is that it has to be
 applied for *every* ModelAdmin that has a ForeignKey to Book, which leads
 to duplication. Ideally, and that is the point of this issue, it would be
 possible to define this select_related business in the Book model or in
 BookAdmin, so it is used automatically.

 I'm not quite sure *how* this would would work and where to put it,
 though. Conceptually, the select_related is needed because of how
 `__str__` is defined on the model, so defining this in the model would
 make sense. There is already the concept of different managers that can
 prepare querysets for different usecases, but I'm not sure if this case
 would warrant a new manager name. If it would, then when would this
 manager be used?

 Conceptually I guess it's not even linked to the
 ForeignKey/ModelChoiceField itself, but it would be the "manager to use
 when you want to call __str__". Since using ModelChoiceField implies
 calling `__str__`, using this custom manager for ModelChoiceField (and/or
 from ForeignKey.dbfield) would also solve the problem, but might apply the
 select_related also in cases where it is not really needed (expanding this
 further, you could of course just add the select_related to the default
 manager, which would work, but end up selecting too much in a lot of
 cases).

 One pragmatic alternative could be to try and fix this at the admin level
 instead, where in this case BookAdmin could define something like
 `get_queryset_for_references()` or so, and have the
 `BookReviewAdmin.get_field_queryset()` use that (similar to how it already
 applies the ordering from the related field admin). Again, not sure how to
 exactly define this in an elegant way...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.goog

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

[Django]

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Mariusz Felisiak ):

 In [changeset:"ea66d1f2ae0053ddbb0c9e0f725dd78cbf70a249" ea66d1f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="ea66d1f2ae0053ddbb0c9e0f725dd78cbf70a249"
 [4.0.x] Refs #33207 -- Clarified that AUTH_USER_MODEL expects an app
 label.

 Backport of fd881e8cd9b7686ab8fcd32332100710a8ffaa10 from main
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.735406c85f9618e5b6801fb380a160cf%40djangoproject.com.

Re: [Django] #33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to get a model

[Django]

#33207: django.apps.apps.get_model() does not allow namespaced (PEP 420) apps to
get a model
--+--
 Reporter:  Jonas L.  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  3.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by GitHub ):

 In [changeset:"fd881e8cd9b7686ab8fcd32332100710a8ffaa10" fd881e8c]:
 {{{
 #!CommitTicketReference repository=""
 revision="fd881e8cd9b7686ab8fcd32332100710a8ffaa10"
 Refs #33207 -- Clarified that AUTH_USER_MODEL expects an app label.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.526e9fb72e78b20b69d95bb657f94f84%40djangoproject.com.

Re: [Django] #18332: No generic way to get database backend version

[Django]

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.9a2c6ab1bb058d97bd451e7735542385%40djangoproject.com.

Re: [Django] #18332: No generic way to get database backend version

[Django]

#18332: No generic way to get database backend version
-+-
 Reporter:  apollovy@…   |Owner:  (none)
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  vanessagomes => (none)
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.157f3fe2fdac389200d663e32b092a89%40djangoproject.com.

Re: [Django] #25197: Add a more friendly widget for HStoreField

[Django]

#25197: Add a more friendly widget for HStoreField
---+
 Reporter:  gam_phon   |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords:  widget | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  1
---+
Changes (by Mariusz Felisiak):

 * owner:  Curtis Maloney => (none)
 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.eee69df03aff5524736d85b1e2f968f5%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.b9388ef69cdb734694dadf0c3e85d0ba%40djangoproject.com.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  Jacob|Owner:  (none)
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Michael Schmidt => (none)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.979a969e673f46db751a4707c1acf913%40djangoproject.com.

Re: [Django] #33062: File upload crash when a file extension contains null characters.

[Django]

#33062: File upload crash when a file extension contains null characters.
--+
 Reporter:  Alex Vandiver |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * owner:  Ased mammad => (none)
 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a59fc519b93eb15fedaf804c053b9ee4%40djangoproject.com.

Re: [Django] #30386: Admin foreign key widgets don't quote keys.

[Django]

#30386: Admin foreign key widgets don't quote keys.
+
 Reporter:  Joshua Goodwin  |Owner:  (none)
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by Mariusz Felisiak):

 * owner:  zeynel => (none)
 * status:  assigned => new


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.f2dc195f86d78f171a936141003c644c%40djangoproject.com.