Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (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 Carlton Gibson):

 Hi Adam.

 It looks to me as if this case is already covered by the test suite (and
 works)...

 We have a
 
[https://github.com/django/django/blob/af8dbbe0d5099ce09fc77abdf8a3fb8a4f4015d9/tests/select_related_onetoone/models.py#L97-L103
 LinkedList model]:


 {{{
 class LinkedList(models.Model):
 name = models.CharField(max_length=50)
 previous_item = models.OneToOneField(
 'self', models.CASCADE,
 related_name='next_item',
 blank=True, null=True,
 )
 }}}

 This is using the `related_name` `'next_item'`.

 Then
 
[https://github.com/django/django/blob/af8dbbe0d5099ce09fc77abdf8a3fb8a4f4015d9/tests/select_related_onetoone/tests.py#L209-L214
 in the test case, we use that in `select_related`]:

 {{{
 def test_self_relation(self):
 item1 = LinkedList.objects.create(name='item1')
 LinkedList.objects.create(name='item2', previous_item=item1)
 with self.assertNumQueries(1):
 item1_db =
 LinkedList.objects.select_related('next_item').get(name='item1')
 self.assertEqual(item1_db.next_item.name, 'item2')
 }}}

-- 
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.6d0e31f01ad09168d619b1fc8db05f6f%40djangoproject.com.

Re: [Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
--+--
 Reporter:  Conor Cunningham  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (URLs)   |  Version:  2.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:  urls, url | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Carlton Gibson):

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


Comment:

 Hi Conor.

 I think this is a mis-understanding on your part here. Alas, it's not
 something we can address directly on the issue tracker. See
 TicketClosingReasons/UseSupportChannels, which I know is where you began…

 `APPEND_SLASH` does not affect the available URLs. Rather it tries an
 additional request to the same URL (if it's missing a slash) to see if
 that matches. Docs for `APPEND_SLASH`.

 > When set to True, if the request URL does not match any of the patterns
 in the URLconf and it doesn’t end in a slash, an HTTP redirect is issued
 to the same URL with a slash appended.

 So I'd try `api/v1/case`, get a 404 and be redirected to `api/v1/case/` to
 give that a chance to match.

 See the docs for [https://docs.djangoproject.com/en/2.2/topics/http/urls
 #including-other-urlconfs Including other URLconfs] to get your
 configuration correct. Note the examples look like this:


 {{{
 from django.urls import include, path

 urlpatterns = [
 # ... snip ...
 path('community/', include('aggregator.urls')),
 path('contact/', include('contact.urls')),
 # ... snip ...
 ]
 }}}

 i.e. they do include the trailing slash when using `include()`.

 (From your screenshot, I'd guess `api/v1case` would match, but that's not
 what you're intending...)

 Good luck.

-- 
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/073.899f552310b757ea5dd145cfbe266142%40djangoproject.com.

Re: [Django] #21961: Add support for database-level cascading options

[Django]

#21961: Add support for database-level cascading options
-+-
 Reporter:  Christophe Pettus|Owner:  Nick
 |  Stefan
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Nick Stefan):

 * cc: Nick Stefan (added)
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8661 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/061.39e6d67bb81119c68fd44284731b1d17%40djangoproject.com.

Re: [Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  explain, analyze,| Triage Stage:  Accepted
  mariadb, mysql |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


-- 
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.5bd77154733e80a7cb24ee6c214718d2%40djangoproject.com.

Re: [Django] #30896: "OperationalError: (1054, "Unknown column ...)" error when running migrations on an empty MySQL database. (was: MySQLdb._exceptions.OperationalError: (1054, "Unknown column ...) e

[Django]

#30896: "OperationalError: (1054, "Unknown column ...)" error when running
migrations on an empty MySQL database.
+--
 Reporter:  coolnodje   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => needsinfo


Comment:

 Thanks for this report, however we will not be able to reproduce this
 issue (or check if it is a duplicate of an existing one) without a small
 sample project or more detailed report.

-- 
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.434e3ab4512601ef4bd6f9d1394e4f36%40djangoproject.com.

Re: [Django] #30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell database shell.

[Django]

#30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell 
database
shell.
-+-
 Reporter:  Simon Charette   |Owner:  Farhaan
 Type:   |  Bukhsh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell database | Triage Stage:  Accepted
  options|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Farhaan Bukhsh):

 Hey Simon, thanks for replying :) I was thinking something similar may be
 a list of all options which is not passed near the dbshell documentation.
 What do you think?

-- 
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.2ae1d99b63ed0612ab8c8d051cb37f8b%40djangoproject.com.

Re: [Django] #30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell database shell.

[Django]

#30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell 
database
shell.
-+-
 Reporter:  Simon Charette   |Owner:  Farhaan
 Type:   |  Bukhsh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell database | Triage Stage:  Accepted
  options|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hello Farhaan, thanks for giving a shot at this ticket!

 I'm not sure where of the best place is for the documentation to live but
 I have a slight preference for `dbshell` since I can't think of another
 place where we special case ''connection'' creation and that was I looked
 for when trying to figure out what was happening.

 I guess a  `..note` pointing to `DATABASE_OPTIONS` mentioning some options
 will be ignored because should do.

-- 
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.ee84b66b831b3b59182ea56bfb031ab5%40djangoproject.com.

Re: [Django] #30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell database shell.

[Django]

#30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell 
database
shell.
-+-
 Reporter:  Simon Charette   |Owner:  Farhaan
 Type:   |  Bukhsh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell database | Triage Stage:  Accepted
  options|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Farhaan Bukhsh):

 * owner:  nobody => Farhaan Bukhsh
 * status:  new => assigned


Comment:

 Hey, I would like to work on this issue. I might need some clarification
 since I am a new contributor. Let me know if I am doing this right, adding
 documentation saying some options might not be available around
 `DATABASES['OPTIONS']` instead near `dbshell` will make it better, right?

 Thanks for the help in advance. :joy:

-- 
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.be1ac0f43f265d76ee8cf8528be7c883%40djangoproject.com.

Re: [Django] #30898: Multi FormSet form Error object has no attribute instance. (was: Multi FormSet form Error object has no attribute instance)

[Django]

#30898: Multi FormSet form Error object has no attribute instance.
-+-
 Reporter:  azharsaleem9 |Owner:
 |  azharsaleem9
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Formsets, forms, | Triage Stage:
  object has no attribute instance   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Please don't use trac as a support channel.

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
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.a1ae290bd5d277c85a63f90b485adbb1%40djangoproject.com.

Re: [Django] #30898: Multi FormSet form Error object has no attribute instance

[Django]

#30898: Multi FormSet form Error  object has no attribute instance
-+-
 Reporter:  azharsaleem9 |Owner:
 |  azharsaleem9
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  Formsets, forms, | Triage Stage:
  object has no attribute instance   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by azharsaleem9):

 * status:  new => assigned
 * owner:  nobody => azharsaleem9


-- 
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.06186e1f5d6a66a31cb79a7c60fc7c69%40djangoproject.com.

[Django] #30898: Multi FormSet form Error object has no attribute instance

[Django]

#30898: Multi FormSet form Error  object has no attribute instance
-+-
   Reporter: |  Owner:  nobody
  azharsaleem9   |
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  2.2
   Severity:  Normal |   Keywords:  Formsets, forms,
   Triage Stage: |  object has no attribute instance
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm working with multi Formset and get this problem. I mentioned my code
 blow please check and help me to solve this issue. Thanks

 **'VoucherEnteryForm' object has no attribute 'instance'**


 == **views.py**

 {{{
 def index(request):
 voucherEnteryFormset = modelformset_factory(
 VoucherEntery, form=VoucherEnteryForm, fields=('group',
 'subGroup', 'obtainMarks', 'totalMarks', 'grade'))
 form = JournalVoucherForm(request.POST or None)
 formset = voucherEnteryFormset(
 request.POST or None, queryset=VoucherEntery.objects.none(),
 prefix='jounarlvoucher')
 if request.method == 'POST':
 if form.is_valid() and formset.is_valid():
 try:
 with transaction.atomic():
 voucher = form.save(commit=False)
 voucher.save()

 for entery in formset:
 data = entery.save(commit=False)
 data.voucher = voucher
 data.save()
 except IntegrityError:
 print('Error Encountered')
 return redirect('home-page')
 context = {
 'formset': formset,
 'form': form
 }
 return render(request, 'myform.html', context)
 }}}


 == **models.py**


 {{{
 class JounarlVoucher(models.Model):
 name = models.CharField(max_length=50)
 datevc = models.DateField(auto_now=False)
 reference = models.CharField(max_length=10)
 jrcode = models.IntegerField()
 createdAt = models.DateTimeField(auto_now_add=True)

 def __str__(self):
 return self.name

 class Meta:
 db_table = "JounarlVoucher"


 class VoucherEntery(models.Model):
 voucher = models.ForeignKey(
 JounarlVoucher, related_name='jounarlvoucher',
 on_delete=models.CASCADE)
 group = models.CharField(max_length=50)
 subGroup = models.CharField(max_length=50)
 obtainMarks = models.IntegerField()
 totalMarks = models.IntegerField()
 grade = models.CharField(max_length=10)
 createdAt = models.DateTimeField(auto_now_add=True)

 def __str__(self):
 return self.voucher

 class Meta:
 db_table = "VoucherEntery"
 }}}


 == **forms.py**


 {{{
 class JournalVoucherForm(forms.Form):
 name = forms.CharField(label='Name', required=True,
 widget=forms.TextInput(
 attrs={
 'class': 'form-control',
 'placeholder': 'Name'
 }
 ))
 datevc = forms.DateField(label='Date', input_formats=['%Y/%m/%d'],
 widget=forms.DateTimeInput(
 attrs={
 'class': 'form-control',
 }
 ))
 reference = forms.CharField(label='Ref', required=False,
 widget=forms.TextInput(
 attrs={
 'class': 'form-control',
 }
 ))
 jrcode = forms.IntegerField(label='Code', required=False,
 widget=forms.NumberInput(
 attrs={
 'class': 'form-control',
 }
 ))


 class VoucherEnteryForm(forms.Form):
 group = forms.ChoiceField(label='Group', required=True,
 choices=myGroup, widget=forms.Select(
 attrs={
 'class': 'form-control formset-field',
 }
 ))
 subGroup = forms.ChoiceField(label='Sub Group', required=True,
 choices=subGroup, widget=forms.Select(
 attrs={
 'class': 'form-control formset-field',
 }
 ))
 obtainMarks = forms.IntegerField(label='Obtain Marks', required=True,
 widget=forms.NumberInput(
 attrs={
 'class': 'form-control formset-field',
 }
 ))
 totalMarks = forms.IntegerField(label='Total Marks', required=True,
 widget=forms.NumberInput(
 attrs={
 'class': 'form-control formset-field',
 }
 ))
 grade = forms.CharField(label='Grade', required=True,
 widget=forms.TextInput(
 attrs={
 'class': 'form-control formset-field',
 }
 ))
 }}}


 == **HTML Template**


 {{{
 
 {% csrf_token %}
 {{ form.as_p }}

 {% for data_frm in formset %}
 
 {{ data_frm.group }}
 {{ data_frm.subGroup }}
 {{ data_frm.obtainMarks }}
 {{ data_frm.total

Re: [Django] #28567: Incompatibility between the set_language() view, LocaleMiddleware, and i18n_patterns() when prefix_default_language=False.

[Django]

#28567: Incompatibility between the set_language() view, LocaleMiddleware, and
i18n_patterns() when prefix_default_language=False.
--+
 Reporter:  George Tantiras   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  master
 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
--+
Changes (by George Tantiras):

 * owner:  George Tantiras => (none)
 * status:  assigned => new


Comment:

 A decision is pending about the suited course of action for this case.

-- 
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.a04208cf36632d7102a35eaed12797bf%40djangoproject.com.

Re: [Django] #26394: Admin images wrong location for selector-search and icon-unknown

[Django]

#26394: Admin images wrong location for selector-search and icon-unknown
---+--
 Reporter:  Kris Avi   |Owner:  (none)
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 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:  1
---+--

Comment (by Dylan Young):

 Hey Kris:  Were you able to track this bug down?

-- 
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.9a246a7b21893140ef8cd849c63b5fd3%40djangoproject.com.

Re: [Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  explain, analyze,| Triage Stage:
  mariadb, mysql |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11955 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/065.75a06a505a7c1ffc7b97ebfdcfaa%40djangoproject.com.

[Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.
-+-
   Reporter:  Nick Pope  |  Owner:  Nick Pope
   Type:  New| Status:  assigned
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:  explain, analyze,
   Severity:  Normal |  mariadb, mysql
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 - MySQL 8.0.16+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-execution-
 plan EXPLAIN FORMAT=TREE].
 - MySQL 8.0.18+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
 EXPLAIN ANALYZE].
 - MariaDB 10.1.0+ has support for [https://mariadb.com/kb/en/library
 /analyze-statement/ ANALYZE]. (Was `EXPLAIN ANALYZE` before 10.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/050.33ebb50cada533a179a4eecef4d6dab1%40djangoproject.com.

Re: [Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
--+--
 Reporter:  Conor Cunningham  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  urls, url | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Conor Cunningham):

 * cc: Conor Cunningham (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/073.202d11d0fdb5b51a67cc8f663742e8a9%40djangoproject.com.

Re: [Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
--+--
 Reporter:  Conor Cunningham  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (URLs)   |  Version:  2.2
 Severity:  Normal|   Resolution:
 Keywords:  urls, url | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Conor Cunningham):

 * Attachment "djang-urls.png" added.

 Screenshot showing a whitespace in URLS that would otherwise be filled by
 a slash if APPEND_SLASH=True

-- 
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/073.be37dd807db2b629f099b8aaa485c04f%40djangoproject.com.

[Django] #30896: MySQLdb._exceptions.OperationalError: (1054, "Unknown column ...) error when `migrate --database=newfreshdb`

[Django]

#30896: MySQLdb._exceptions.OperationalError: (1054, "Unknown column ...) error
when `migrate --database=newfreshdb`
--+
   Reporter:  coolnodje   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  2.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   |
--+
 I keep hitting this problem while trying to replay an entire database
 migrations on a new fresh DB (from MySQL to PostgreSQL to be precise).

 MySQL complains of a non existing column that was removed in a later stage
 of migrations.
 This column doesn't exist in MySQL anymore as it is up to date with the
 newest migration. So it's only natural that the column cannot be found.

 The question is: why is `migrate` looking for this column at this stage?
 It can only be found in the target new DB.

 I'm not including any code at this stage but I guess I can probably find a
 way to share the whole migrations if this doesn't sound like an already
 addressed problem.

-- 
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/048.6c64e3f3945c0abcf9f5d774e28e5f7d%40djangoproject.com.

Re: [Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
-+--
 Reporter:  conorcunningham  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  urls, url| 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 conorcunningham:

Old description:

> I'm not sure whether this is a feature or a bug, but failing in my
> attempt to get an answer in #django or django-users, I thought it best to
> report it.
> I have come
>
> === Summary
> In short I have a URL which will be either ```/api/v1/case/``` if
> ```APPEND_SLASH=True,``` or ```/api/v1 case``` if ```APPEND_SLASH =
> False```.
> The URL ```/api/v1/case/``` is made up of two URLS, namely ```/api/v1```
> and ```/case```, one from the projects ```urls.py``` and the other from
> the app's ```urls.py```. What I suspect is happening is that a trailing
> slash is being appended to both the URLS before they are concatenated to
> make the final URL.
>
> **Django Version**: 2.2.6
> **Installed Apps**:
> django-allauth==0.40.0
> django-cors-headers==3.1.1
> django-crispy-forms==1.7.2
> django-environ==0.4.5
> django-rest-auth==0.9.5
> django-rest-swagger==2.2.0
> djangorestframework==3.10.3
> djangorestframework-simplejwt==4.3.0
>

> === Reproduction
> It should be first mentioned that I am using DRF to provide API
> functionality for my views mentioned herein, and that I am using Docker
> both locally for development, and on the production server. The issue is
> reproducible in both environments.
>
> I should also note that I can avoid this behaviour by configuring the
> URLs in a different (what I presume to be the correct way)
>
> To reproduce this, I have a project ```urls.py``` file with the following
>
> ```path('api/v1', include('api.urls')),``` - (note there is no trailing
> slash)
>
> And an app called **api** with a URL file, ```api/urls.py``` with the
> following
>
> ```path('case', CasesView.as_view(), name='all-cases'),```
>
> If you have a URL configured as above and ```APPEND_SLASH=True``` you
> will be able to navigate to the URL ```/api/v1/case/```. If
> ```APPEND_SLASH=False```, then navigating to the aforementioned URL, you
> will receive a 404 and Django debug will report that it tried a URL of
> ```/api/v1 case```
>
> In addition to what appears to be two slashes being rendered into the
> final URL, I am also curious as to where the blank space in the URL
> ```/api/v1 case``` comes from, as there is no whitespace in either of the
> two configured URLs.
>
> I can avoid this behaviour entirely, regardless of what
> ```APPEND_SLASH``` is set, by configuring the project URl as:
> ```path('api/v1/', include('api.urls')),```
>
> and the app URL as:
>
> ```path('case', CasesView.as_view(), name='all-cases'),```
>
> The difference only being in that I have hardcoded a trailing slash into
> the project URL's path.
>
> === Final Thoughts
>
> The reason I think this is a bug, is that the behaviour, at least to me
> is non-obvious. That's not to say when you stop and think about it that
> it isn't perhaps logical, if indeed there are two URLs which have slashes
> appended to them in order to make the final URL, but on first glance when
> I read about Django's APPEND_SLASH feature, I think of the final URL, the
> one that the user will see, not of two separate URLs  that are being put
> together to make the final product.
>
> However, the thing that makes me think that perhaps this isn't a bug, is
> that I seemingly just didn't configure Django properly. It could be as
> simple as that, and I apologise if that is the case.
>
> I am only too happy to provide any further information that may be of use
> in investigating this issue, if indeed it turns out to be an issue.
>
> Cheers,
>
> Conor

New description:

 I'm not sure whether this is a feature or a bug, but failing in my attempt
 to get an answer in #django or django-users, I thought it best to report
 it.

 === Summary
 In short I have a URL which will be either ```/api/v1/case/``` if
 ```APPEND_SLASH=True,``` or ```/api/v1 case``` if ```APPEND_SLASH =
 False```.
 The URL ```/api/v1/case/``` is made up of two URLS, namely ```/api/v1```
 and ```/case```, one from the projects ```urls.py``` and the other from
 the app's ```urls.py```. What I suspect is happening is that a trailing
 slash is being appended to both the URLS before they are concatenated to
 make the final URL.

 **Django Version**: 2.2.6
 **Installed Apps**:
 django-allauth==0.40.0
 django-cors-headers==3.1.1
 djang

[Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
---+---
   Reporter:  conorcunningham  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (URLs)  |Version:  2.2
   Severity:  Normal   |   Keywords:  urls, url
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
 I'm not sure whether this is a feature or a bug, but failing in my attempt
 to get an answer in #django or django-users, I thought it best to report
 it.
 I have come

 === Summary
 In short I have a URL which will be either ```/api/v1/case/``` if
 ```APPEND_SLASH=True,``` or ```/api/v1 case``` if ```APPEND_SLASH =
 False```.
 The URL ```/api/v1/case/``` is made up of two URLS, namely ```/api/v1```
 and ```/case```, one from the projects ```urls.py``` and the other from
 the app's ```urls.py```. What I suspect is happening is that a trailing
 slash is being appended to both the URLS before they are concatenated to
 make the final URL.

 **Django Version**: 2.2.6
 **Installed Apps**:
 django-allauth==0.40.0
 django-cors-headers==3.1.1
 django-crispy-forms==1.7.2
 django-environ==0.4.5
 django-rest-auth==0.9.5
 django-rest-swagger==2.2.0
 djangorestframework==3.10.3
 djangorestframework-simplejwt==4.3.0


 === Reproduction
 It should be first mentioned that I am using DRF to provide API
 functionality for my views mentioned herein, and that I am using Docker
 both locally for development, and on the production server. The issue is
 reproducible in both environments.

 I should also note that I can avoid this behaviour by configuring the URLs
 in a different (what I presume to be the correct way)

 To reproduce this, I have a project ```urls.py``` file with the following

 ```path('api/v1', include('api.urls')),``` - (note there is no trailing
 slash)

 And an app called **api** with a URL file, ```api/urls.py``` with the
 following

 ```path('case', CasesView.as_view(), name='all-cases'),```

 If you have a URL configured as above and ```APPEND_SLASH=True``` you will
 be able to navigate to the URL ```/api/v1/case/```. If
 ```APPEND_SLASH=False```, then navigating to the aforementioned URL, you
 will receive a 404 and Django debug will report that it tried a URL of
 ```/api/v1 case```

 In addition to what appears to be two slashes being rendered into the
 final URL, I am also curious as to where the blank space in the URL
 ```/api/v1 case``` comes from, as there is no whitespace in either of the
 two configured URLs.

 I can avoid this behaviour entirely, regardless of what ```APPEND_SLASH```
 is set, by configuring the project URl as:
 ```path('api/v1/', include('api.urls')),```

 and the app URL as:

 ```path('case', CasesView.as_view(), name='all-cases'),```

 The difference only being in that I have hardcoded a trailing slash into
 the project URL's path.

 === Final Thoughts

 The reason I think this is a bug, is that the behaviour, at least to me is
 non-obvious. That's not to say when you stop and think about it that it
 isn't perhaps logical, if indeed there are two URLs which have slashes
 appended to them in order to make the final URL, but on first glance when
 I read about Django's APPEND_SLASH feature, I think of the final URL, the
 one that the user will see, not of two separate URLs  that are being put
 together to make the final product.

 However, the thing that makes me think that perhaps this isn't a bug, is
 that I seemingly just didn't configure Django properly. It could be as
 simple as that, and I apologise if that is the case.

 I am only too happy to provide any further information that may be of use
 in investigating this issue, if indeed it turns out to be an issue.

 Cheers,

 Conor

-- 
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/058.8bb531a7155fc4f170a5ce03c5535fb3%40djangoproject.com.

Re: [Django] #30892: slugify() doesn't return a valid slug for "İ".

[Django]

#30892: slugify() doesn't return a valid slug for "İ".
---+
 Reporter:  Luis Nell  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 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 Luis Nell):

 True that.

 I also thought about looping over the characters and simply removing
 everything that does not match the `\w`. However, I threw that away
 because I thought that this might as well hit some edge case where it
 could modify the meaning of a word.

 In any case, if we can find a (more solid) process, I'd be very happy to
 produce a patch and tests for that.

-- 
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.56b57b948c1196a949a077b74a0618fa%40djangoproject.com.

Re: [Django] #20577: Make prefetch_related faster by lazily creating related querysets

[Django]

#20577: Make prefetch_related faster by lazily creating related querysets
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Alex
 Type:   |  Aktsipetrov
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"681f7e2b13846def9eff3d26ce1371d05fa90c4c" 681f7e2]:
 {{{
 #!CommitTicketReference repository=""
 revision="681f7e2b13846def9eff3d26ce1371d05fa90c4c"
 Fixed #20577 -- Deferred filtering of prefetched related querysets.

 Added internal interface to QuerySet that allows to defer next filter
 call till .query is accessed. Used it to optimize prefetch_related().

 Thanks Simon Charette for the review.
 }}}

-- 
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.dd2ce1bfec4d7cb20e64d5c0568ea026%40djangoproject.com.

Re: [Django] #30892: slugify() doesn't return a valid slug for "İ". (was: Slugify and SlugField with Diacritics)

[Django]

#30892: slugify() doesn't return a valid slug for "İ".
---+
 Reporter:  Luis Nell  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 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
---+
Changes (by felixxm):

 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this ticket. I'm not sure if your solution is correct because
 I'm afraid that we may hit another edge case, nevertheless `slugify()`
 should return a valid slug.

-- 
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.e8055eca7c61e3f3a475b761e2a0df47%40djangoproject.com.

Re: [Django] #20577: Make prefetch_related faster by lazily creating related querysets

[Django]

#20577: Make prefetch_related faster by lazily creating related querysets
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Alex
 Type:   |  Aktsipetrov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


-- 
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.b26c452e9daebca7b0976132f0e97a6e%40djangoproject.com.

Re: [Django] #20577: Make prefetch_related faster by lazily creating related querysets

[Django]

#20577: Make prefetch_related faster by lazily creating related querysets
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Alex
 Type:   |  Aktsipetrov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

 * owner:  nobody => Alex Aktsipetrov
 * status:  new => assigned


Comment:

 [https://github.com/django/django/pull/11916 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/066.21b94b1709d5223a6cc263c1accb5595%40djangoproject.com.

Re: [Django] #30827: bulk_create batch_size param overrides the compatible batch size calculation

[Django]

#30827: bulk_create batch_size param overrides the compatible batch size
calculation
-+-
 Reporter:  Ahmet Kucuk  |Owner:  Ahmet
 |  Kucuk
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"09578f6dfb757c55f107e30a85434cedeb47465a" 09578f6]:
 {{{
 #!CommitTicketReference repository=""
 revision="09578f6dfb757c55f107e30a85434cedeb47465a"
 Fixed #30827 -- Made batch_size arg of QuerySet.bulk_create() respect
 DatabaseOperations.bulk_batch_size().

 Thanks Chetan Khanna for tests.
 }}}

-- 
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.9a945ad625792c348f9d838e5120ac73%40djangoproject.com.

[Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
   Reporter:  Adam   |  Owner:  nobody
  Sołtysik   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  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  |
-+-
 The documentation
 (https://docs.djangoproject.com/en/2.2/ref/models/querysets/#select-
 related) states:

   You can also refer to the reverse direction of a OneToOneField in the
 list of fields passed to select_related — that is, you can traverse a
 OneToOneField back to the object on which the field is defined. Instead of
 specifying the field name, use the related_name for the field on the
 related object.

 But in fact `related_query_name` is used by `select_related` and
 `related_name` is used by `prefetch_related` .

 When we have the following models:

 {{{
 class A(Model):
 pass
 }}}
 {{{
 class B(Model):
 a = OneToOneField('A', related_name='b_set', related_query_name='b')
 }}}

 then `a.select_related('b')` works and `a.prefetch_related('b')` does not:

 {{{AttributeError: Cannot find 'b' on A object, 'b' is an invalid
 parameter to prefetch_related()}}}

 or if class `A` happens to have a property named `b`:

 {{{ValueError: 'b' does not resolve to an item that supports prefetching -
 this is an invalid parameter to prefetch_related().}}}

 And vice versa, `a.prefetch_related('b_set')` works and
 `a.select_related('b_set')` does not:

 {{{django.core.exceptions.FieldError: Invalid field name(s) given in
 select_related: 'b_set'. Choices are: b}}}

 The documentation implies that both methods should use `related_name`, but
 I think it would be more intuitive if both used `related_query_name`,
 given that we can write lookups like in filter queries etc., and such a
 change would probably be less backward-incompatible.

-- 
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.36f6257cfdfa7c555f215e655bf9a533%40djangoproject.com.

Re: [Django] #30827: bulk_create batch_size param overrides the compatible batch size calculation

[Django]

#30827: bulk_create batch_size param overrides the compatible batch size
calculation
-+-
 Reporter:  Ahmet Kucuk  |Owner:  Ahmet
 |  Kucuk
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Ahmet Kucuk
 * status:  new => assigned
 * version:  2.2 => master
 * stage:  Accepted => Ready for checkin


-- 
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.96cfe6ebb54c93b7ef1450d9514d5ea6%40djangoproject.com.

Re: [Django] #30827: bulk_create batch_size param overrides the compatible batch size calculation

[Django]

#30827: bulk_create batch_size param overrides the compatible batch size
calculation
-+-
 Reporter:  Ahmet Kucuk  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by felixxm):

 Chetan Khanna, thanks, I added your test to the patch.

-- 
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.9a8c2b162d1a39a808052cf2dd952159%40djangoproject.com.

Re: [Django] #30876: Move `django.utils.decorators.classproperty` to `django.utils.functional`.

[Django]

#30876: Move `django.utils.decorators.classproperty` to 
`django.utils.functional`.
---+-
 Reporter:  André Ericson  |Owner:  André Ericson
 Type:  New feature|   Status:  closed
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"312049091288dbba2299de8d07ea3e3311ed7238" 31204909]:
 {{{
 #!CommitTicketReference repository=""
 revision="312049091288dbba2299de8d07ea3e3311ed7238"
 Fixed #30876 -- Moved classproperty() decorator to the
 django.utils.functional.
 }}}

-- 
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.1440481c03851b7b35d45b3098efe900%40djangoproject.com.

Re: [Django] #30841: Prevent using __isnull lookup with non-boolean value.

[Django]

#30841: Prevent using  __isnull lookup with non-boolean value.
-+-
 Reporter:  André Ericson|Owner:  André
 Type:   |  Ericson
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"31174031f1ded30d96c77908b965755e0be94c94" 3117403]:
 {{{
 #!CommitTicketReference repository=""
 revision="31174031f1ded30d96c77908b965755e0be94c94"
 Fixed #30841 -- Deprecated using non-boolean values for isnull lookup.
 }}}

-- 
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.987dfb14b370bac0e9a73bb6dfe271f8%40djangoproject.com.

Re: [Django] #30841: Prevent using __isnull lookup with non-boolean value.

[Django]

#30841: Prevent using  __isnull lookup with non-boolean value.
-+-
 Reporter:  André Ericson|Owner:  André
 Type:   |  Ericson
  Cleanup/optimization   |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


-- 
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.62587a2cf6d3c15be5471d8c5441bdcb%40djangoproject.com.