Re: [Django] #28444: Allow for different settings for each thread when testing with --parallel

2017-07-28 Thread Django
#28444: Allow for different settings for each thread when testing with 
--parallel
---+--
 Reporter:  Leonardo Arroyo|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.11
 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 Tim Graham):

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


Comment:

 Or maybe your test settings file could make use of
 [https://docs.python.org/3/library/threading.html#threading.get_ident
 threading.get_ident()] to construct the index name? Like Tom, I'm also not
 immediately convinced that this would be generally useful. Feel free to to
 put together a proof of concept and write to the DevelopersMailingList to
 see what others 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.b289d8438651c19508ebfb21064d6afc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28440: Runserver does not correctly close connections once a response is sent

2017-07-28 Thread Django
#28440: Runserver does not correctly close connections once a response is sent
-+
 Reporter:  Tom  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Release blocker  |   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 Tom):

 The issue appears to be that the `CommonMiddleware` sets the `Content-
 Length` header, which causes the server to close the connection. When this
 header is not present (or the middleware not installed) the server
 continues to wait.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.824b4ef1a38bbc413399b2693dbb0c9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28440: Runserver does not correctly close connections once a response is sent

2017-07-28 Thread Django
#28440: Runserver does not correctly close connections once a response is sent
-+
 Reporter:  Tom  |Owner:  Tom
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Release blocker  |   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 Tom):

 * owner:  nobody => Tom
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.72d0aac688432c4981aa582f9f8b7e9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27994: Document contrib.staticfiles.storage.ManifestFilesMixin

2017-07-28 Thread Django
#27994: Document contrib.staticfiles.storage.ManifestFilesMixin
-+-
 Reporter:  GabrielDumbrava  |Owner:  Theofanis
 |  Despoudis
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  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 Tim Graham):

 * has_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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.6c01e41ccbe10480fc7ec12678c9b09c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28445: DateField timezone issue with get_or_create (duplicate key value violates unique constraint)

2017-07-28 Thread Django
#28445: DateField timezone issue with get_or_create (duplicate key value 
violates
unique constraint)
-+-
 Reporter:  Jure Erznožnik   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  orm timezone | Triage Stage:
  get_or_create  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 The `date=timezone.now().date()` code looks suspicious. Since the field
 has `auto_now=True`, it uses
 
[https://github.com/django/django/blob/99e7bba443e3ff1a115d930dbb6dfcf9bccb027c/django/db/models/fields/__init__.py#L1249
 datetime.date.today()] as the creation value, regardless of you provide.
 I'd suggest replacing `date=timezone.now().date()` with
 `date=datetime.date.today()` and checking if the issue still happens.
 Please reopen the ticket if you identify that Django is really at fault.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bb54ab7abf159d755c3e2d498a1b004e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28442: Error creating queryset with nested OuterRefs on a foreign key

2017-07-28 Thread Django
#28442: Error creating queryset with nested OuterRefs on a foreign key
-+-
 Reporter:  Abram Booth  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Tim Graham):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fb9d77eddedaaa800f5a14dd5e8d1dbd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

2017-07-28 Thread Django
#23919: Cleanups for when we drop Python 2 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:
 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 Tom):

 * cc: Tom (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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.79516928cdf75524e0081b8c5bb62d98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27685: Allow autoreloader to use watchman

2017-07-28 Thread Django
#27685: Allow autoreloader to use watchman
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 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 Tom):

 * has_patch:  0 => 1


Comment:

 I have a potential start of a patch here:
 https://github.com/django/django/pull/8819

 I think the first step is to refactor/re-write the autoreloader, and the
 next step is to add support for interesting things like watchman. The MR
 linked above is the start of the refactor.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.96a7605497a79dd7bdc00a72219051c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28440: Runserver does not correctly close connections once a response is sent

2017-07-28 Thread Django
#28440: Runserver does not correctly close connections once a response is sent
-+
 Reporter:  Tom  |Owner:  Tom
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Release blocker  |   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 Tom):

 So this actually appears to be a bug in the `http.server` module. If you
 use HTTP/1.1 with `Connection: keep-alive` and *dont* send a Content-
 Length header the connection will hang forever. You can test this with a
 little tinkering in the `http.server` module itself, and running `python3
 -mhttp.server` on your machine.

 I've made a PR (https://github.com/django/django/pull/8820) to simply
 disable keep-alive for now.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.b0057e56109ed35ee99b8c0243d2b2a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28440: Runserver does not correctly close connections once a response is sent

2017-07-28 Thread Django
#28440: Runserver does not correctly close connections once a response is sent
-+
 Reporter:  Tom  |Owner:  Tom
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Release blocker  |   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 Tom):

 * has_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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.07ef052f3c99e26c75d213608f9a54bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #28445: DateField timezone issue with get_or_create (duplicate key value violates unique constraint)

2017-07-28 Thread Django
#28445: DateField timezone issue with get_or_create (duplicate key value 
violates
unique constraint)
-+-
   Reporter:  Jure   |  Owner:  nobody
  Erznožnik  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|   Keywords:  orm timezone
   Severity:  Normal |  get_or_create
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 My model:


 {{{
 class AccessUseByDomain(models.Model):
 domain = models.IntegerField(verbose_name=_('Domain'),
 choices=settings.DOMAINS, null=True, blank=True)
 date = models.DateField(verbose_name=_('Date'), auto_now=True)
 no_access = models.IntegerField(verbose_name=_('Accesses'))

 class Meta:
 unique_together = [
 ['domain', 'date']  # Logic.consume_access
 ]

 }}}

 The code that leads to error:
 {{{
 c, unused =
 AccessUseByDomain.objects.get_or_create(domain=device.hw_domain,
 date=timezone.now().date(),
 defaults=dict(no_access=0))
 c.no_access += 1
 c.save()
 }}}

 Queries generated in this code block:
 •   {'sql': 'SELECT "my_team_accessusebydomain"."id",
 "my_team_accessusebydomain"."domain", "my_team_accessusebydomain"."date",
 "my_team_accessusebydomain"."no_access" FROM "my_team_accessusebydomain"
 WHERE ("my_team_accessusebydomain"."domain" = 0 AND
 "my_team_accessusebydomain"."date" = \'2017-07-27\'::date)', 'time':
 '0.001'}
 •   {'sql': 'SAVEPOINT "s140667396605696_x4"', 'time': '0.000'}
 •   {'sql': 'INSERT INTO "my_team_accessusebydomain" ("domain",
 "date", "no_access") VALUES (0, \'2017-07-28\'::date, 0) RETURNING
 "my_team_accessusebydomain"."id"', 'time': '0.003'}
 •   {'sql': 'ROLLBACK TO SAVEPOINT "s140667396605696_x4"', 'time':
 '0.000'}
 •   {'sql': 'RELEASE SAVEPOINT "s140667396605696_x4"', 'time':
 '0.000'}
 •   {'sql': 'SELECT "my_team_accessusebydomain"."id",
 "my_team_accessusebydomain"."domain", "my_team_accessusebydomain"."date",
 "my_team_accessusebydomain"."no_access" FROM "my_team_accessusebydomain"
 WHERE ("my_team_accessusebydomain"."domain" = 0 AND
 "my_team_accessusebydomain"."date" = \'2017-07-27\'::date)', 'time':
 '0.000'}
 **(please note the different date generated between selects and insert)**

 Relevant settings.py section:
 {{{
 LANGUAGE_CODE = 'en-gb'
 TIME_ZONE = 'Europe/Ljubljana'
 USE_I18N = True
 USE_L10N = True
 USE_TZ = True
 }}}

 **When this happens:**
 I'm getting this error between midnight and 2am on the server (the code is
 not client-dependent, I hope). As it happens, the server is in CET
 timezone, which is +2 right now. Naturally, the code in question has to be
 run at least twice.

 It would seem that either get or create part of the get_or_create does not
 do appropriate timezone adjustments for the date provided in the filter.
 My bet is on the get part (the date in INSERT statement is the correct
 one).

 Note: I'm sorry I can't test this on 1.11, as I'm using
 MultipleChoiceField in forms and haven't figured out a way to replace it
 yet. The release notes only say those (undocumented classes) were removed,
 but nothing on what to use instead. I can confirm though that 1.9 exhibits
 the same behaviour.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.05f982bf725a217e66410273410672d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28443: MultiValueField does not work with ModelChoiceField?

2017-07-28 Thread Django
#28443: MultiValueField does not work with ModelChoiceField?
---+--
 Reporter:  adam-kral  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.11
 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
---+--
Description changed by adam-kral:

Old description:

> The code: (where AddressInput is a MultiWidget)
>
> {{{#!python
> class AddressInput(widgets.MultiWidget):
> def __init__(self, attrs=None):
> self.widgets = widgets.HiddenInput(attrs),
> widgets.TextInput(attrs). # note that the second widget would be
> customized, I'm only providing simplified example, which does produce the
> same error
> super().__init__(self.widgets, attrs)
>
> def decompress(self, value):
> try:
> address = AddressPoint.objects.get(pk=value)
> except (AddressPoint.DoesNotExist, ValueError):
> address = None
>
> return [value, str(address)]
>
> def value_from_datadict(self, data, files, name):
> return tuple(widget.value_from_datadict(data, files,
> f'{name}_{i}') for i, widget in enumerate(self.widgets))
>

> class AddressFormField(MultiValueField):
> widget = AddressInput
>
> def __init__(self, queryset, empty_label="-",
> to_field_name=None, limit_choices_to=None, *args, **kwargs):
> fields = (
> ModelChoiceField(queryset, empty_label=empty_label,
> to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
> **kwargs),
> CharField()
> )
>
> super().__init__(fields=fields, require_all_fields=False, *args,
> **kwargs)
>
> #self.widget.choices = self.fields[0].widget.choices   if not
> commented out, I get another error: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'
>
> def compress(self, data_list):
> if not data_list[1]:
> return None
>
> if not data_list[0]:
> raise ValidationError('Invalid address')
>
> return data_list[0]
>

> class AddressForeignKey(ForeignKey):
> def formfield(self, **kwargs):
> # This is a fairly standard way to set up some defaults
> # while letting the caller override them.
> defaults = {'form_class': AddressFormField}
> defaults.update(kwargs)
> return super().formfield(**defaults)
> }}}
> I get this error: AttributeError: 'AddressInput' object has no attribute
> 'choices'
> Because ModelChoiceField did not declare it. Passing the widget to
> ModelChoiceField does not work as it makes a copy if it's an instance.
> Thus I set the choices attribute manually as you can see in the commented
> out code.
> But then I got another error which I didn't resolve: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

New description:

 The code: (where AddressInput is a MultiWidget)

 {{{#!python
 class AddressInput(widgets.MultiWidget):
 def __init__(self, attrs=None):
 self.widgets = widgets.HiddenInput(attrs),
 widgets.TextInput(attrs) # note that the second widget would be
 customized, I'm only providing simplified example, which does produce the
 same error
 super().__init__(self.widgets, attrs)

 def decompress(self, value):
 try:
 address = AddressPoint.objects.get(pk=value)
 except (AddressPoint.DoesNotExist, ValueError):
 address = None

 return [value, str(address)]

 def value_from_datadict(self, data, files, name):
 return tuple(widget.value_from_datadict(data, files,
 f'{name}_{i}') for i, widget in enumerate(self.widgets))


 class AddressFormField(MultiValueField):
 widget = AddressInput

 def __init__(self, queryset, empty_label="-",
 to_field_name=None, limit_choices_to=None, *args, **kwargs):
 fields = (
 ModelChoiceField(queryset, empty_label=empty_label,
 to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
 **kwargs),
 CharField()
 )

 super().__init__(fields=fields, require_all_fields=False, *args,
 **kwargs)

 #self.widget.choices = self.fields[0].widget.choices   if not
 commented out, I get another error: AttributeError:
 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

 def compress(self, data_list):
 if not data_list[1]:
 return None

 if not data_list[0]:
 raise ValidationError('Invalid address')

 return data_list[0]


 class 

Re: [Django] #28443: MultiValueField does not work with ModelChoiceField?

2017-07-28 Thread Django
#28443: MultiValueField does not work with ModelChoiceField?
---+--
 Reporter:  adam-kral  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.11
 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
---+--
Description changed by adam-kral:

Old description:

> The code: (where AddressInput is a MultiWidget)
>
> {{{#!python
> class AddressFormField(MultiValueField):
> widget = AddressInput
>
> def __init__(self, queryset, empty_label="-",
> to_field_name=None, limit_choices_to=None, *args, **kwargs):
> fields = (
> ModelChoiceField(queryset, empty_label=empty_label,
> to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
> **kwargs),
> CharField()
> )
>
> super().__init__(fields=fields, require_all_fields=False, *args,
> **kwargs)
>
> #self.widget.choices = self.fields[0].widget.choices   if not
> commented out, I get another error: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'
>
> def compress(self, data_list):
> if not data_list[1]:
> return None
>
> if not data_list[0]:
> raise ValidationError('Invalid address')
>
> return data_list[0]
>

> class AddressForeignKey(ForeignKey):
> def formfield(self, **kwargs):
> # This is a fairly standard way to set up some defaults
> # while letting the caller override them.
> defaults = {'form_class': AddressFormField}
> defaults.update(kwargs)
> return super().formfield(**defaults)
> }}}
> I get this error: AttributeError: 'AddressInput' object has no attribute
> 'choices'
> Because ModelChoiceField did not declare it. Passing the widget to
> ModelChoiceField does not work as it makes a copy if it's an instance.
> Thus I set the choices attribute manually as you can see in the commented
> out code.
> But then I got another error which I didn't resolve: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

New description:

 The code: (where AddressInput is a MultiWidget)

 {{{#!python
 class AddressInput(widgets.MultiWidget):
 def __init__(self, attrs=None):
 self.widgets = widgets.HiddenInput(attrs),
 widgets.TextInput(attrs). # note that the second widget would be
 customized, I'm only providing simplified example, which does produce the
 same error
 super().__init__(self.widgets, attrs)

 def decompress(self, value):
 try:
 address = AddressPoint.objects.get(pk=value)
 except (AddressPoint.DoesNotExist, ValueError):
 address = None

 return [value, str(address)]

 def value_from_datadict(self, data, files, name):
 return tuple(widget.value_from_datadict(data, files,
 f'{name}_{i}') for i, widget in enumerate(self.widgets))


 class AddressFormField(MultiValueField):
 widget = AddressInput

 def __init__(self, queryset, empty_label="-",
 to_field_name=None, limit_choices_to=None, *args, **kwargs):
 fields = (
 ModelChoiceField(queryset, empty_label=empty_label,
 to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
 **kwargs),
 CharField()
 )

 super().__init__(fields=fields, require_all_fields=False, *args,
 **kwargs)

 #self.widget.choices = self.fields[0].widget.choices   if not
 commented out, I get another error: AttributeError:
 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

 def compress(self, data_list):
 if not data_list[1]:
 return None

 if not data_list[0]:
 raise ValidationError('Invalid address')

 return data_list[0]


 class AddressForeignKey(ForeignKey):
 def formfield(self, **kwargs):
 # This is a fairly standard way to set up some defaults
 # while letting the caller override them.
 defaults = {'form_class': AddressFormField}
 defaults.update(kwargs)
 return super().formfield(**defaults)
 }}}
 I get this error: AttributeError: 'AddressInput' object has no attribute
 'choices'
 Because ModelChoiceField did not declare it. Passing the widget to
 ModelChoiceField does not work as it makes a copy if it's an instance.
 Thus I set the choices attribute manually as you can see in the commented
 out code.
 But then I got another error which I didn't resolve: AttributeError:
 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

--


Re: [Django] #28443: MultiValueField does not work with ModelChoiceField?

2017-07-28 Thread Django
#28443: MultiValueField does not work with ModelChoiceField?
---+--
 Reporter:  adam-kral  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.11
 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
---+--
Description changed by adam-kral:

Old description:

> The code: (where AddressInput is a MultiWidget)
>
> {{{#!python
> class AddressInput(widgets.MultiWidget):
> def __init__(self, attrs=None):
> self.widgets = widgets.HiddenInput(attrs),
> widgets.TextInput(attrs) # note that the second widget would be
> customized, I'm only providing simplified example, which does produce the
> same error
> super().__init__(self.widgets, attrs)
>
> def decompress(self, value):
> try:
> address = AddressPoint.objects.get(pk=value)
> except (AddressPoint.DoesNotExist, ValueError):
> address = None
>
> return [value, str(address)]
>
> def value_from_datadict(self, data, files, name):
> return tuple(widget.value_from_datadict(data, files,
> f'{name}_{i}') for i, widget in enumerate(self.widgets))
>

> class AddressFormField(MultiValueField):
> widget = AddressInput
>
> def __init__(self, queryset, empty_label="-",
> to_field_name=None, limit_choices_to=None, *args, **kwargs):
> fields = (
> ModelChoiceField(queryset, empty_label=empty_label,
> to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
> **kwargs),
> CharField()
> )
>
> super().__init__(fields=fields, require_all_fields=False, *args,
> **kwargs)
>
> #self.widget.choices = self.fields[0].widget.choices   if not
> commented out, I get another error: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'
>
> def compress(self, data_list):
> if not data_list[1]:
> return None
>
> if not data_list[0]:
> raise ValidationError('Invalid address')
>
> return data_list[0]
>

> class AddressForeignKey(ForeignKey):
> def formfield(self, **kwargs):
> # This is a fairly standard way to set up some defaults
> # while letting the caller override them.
> defaults = {'form_class': AddressFormField}
> defaults.update(kwargs)
> return super().formfield(**defaults)
> }}}
> I get this error: AttributeError: 'AddressInput' object has no attribute
> 'choices'
> Because ModelChoiceField did not declare it. Passing the widget to
> ModelChoiceField does not work as it makes a copy if it's an instance.
> Thus I set the choices attribute manually as you can see in the commented
> out code.
> But then I got another error which I didn't resolve: AttributeError:
> 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

New description:

 The code: (where AddressInput is a MultiWidget)

 {{{#!python
 class AddressInput(widgets.MultiWidget):
 def __init__(self, attrs=None):
 self.widgets = widgets.HiddenInput(attrs),
 widgets.TextInput(attrs) # note that the second widget would be
 customized, I'm only providing simplified example, which does produce the
 same error
 super().__init__(self.widgets, attrs)

 def decompress(self, value):
 try:
 address = AddressPoint.objects.get(pk=value)
 except (AddressPoint.DoesNotExist, ValueError):
 address = None

 return [value, str(address)]


 class AddressFormField(MultiValueField):
 widget = AddressInput

 def __init__(self, queryset, empty_label="-",
 to_field_name=None, limit_choices_to=None, *args, **kwargs):
 fields = (
 ModelChoiceField(queryset, empty_label=empty_label,
 to_field_name=to_field_name, limit_choices_to=limit_choices_to, *args,
 **kwargs),
 CharField()
 )

 super().__init__(fields=fields, require_all_fields=False, *args,
 **kwargs)

 #self.widget.choices = self.fields[0].widget.choices   if not
 commented out, I get another error: AttributeError:
 'RelatedFieldWidgetWrapper' object has no attribute 'decompress'

 def compress(self, data_list):
 if not data_list[1]:
 return None

 if not data_list[0]:
 raise ValidationError('Invalid address')

 return data_list[0]


 class AddressForeignKey(ForeignKey):
 def formfield(self, **kwargs):
 # This is a fairly standard way to set up some defaults
 # while letting the caller override them.
   

Re: [Django] #27994: Document contrib.staticfiles.storage.ManifestFilesMixin

2017-07-28 Thread Django
#27994: Document contrib.staticfiles.storage.ManifestFilesMixin
-+-
 Reporter:  GabrielDumbrava  |Owner:  Theofanis
 |  Despoudis
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.10
 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 Theofanis Despoudis):

 PR Here
 https://github.com/django/django/pull/8803

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.9af364a7807160143547db79988cb1c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2 4d2925d6"

2017-07-28 Thread Django
#28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2
4d2925d6"
-+-
 Reporter:  Lyle Scott III   |Owner:  Lyle
 Type:   |  Scott III
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  geos version | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Old description:

> I updated Python via brew yesterday (3.6.1 to 3.6.2) and have been having
> problems running Django since then.
> https://code.djangoproject.com/ticket/28441 references the issue, but for
> Django 1.11.x. Looking at the PR for that ticket,
> https://github.com/django/django/pull/8817, it looks like that is not a
> clean patch to Django 1.10.x
>
> * macOS Sierra - 10.12.5 (16F73)
> * Homebrew 1.2.5
> * Python 3.6.2 from brew
>
> {{{
> Traceback (most recent call last):
>   File "gooee_django/manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/core/management/__init__.py", line 367, in
> execute_from_command_line
> utility.execute()
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/core/management/__init__.py", line 341, in execute
> django.setup()
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/__init__.py", line 27, in setup
> apps.populate(settings.INSTALLED_APPS)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/apps/registry.py", line 108, in populate
> app_config.import_models(all_models)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/apps/config.py", line 199, in import_models
> self.models_module = import_module(models_module_name)
>   File
> "/Users/lyle/.virtualenvs/project/lib/python3.6/importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 978, in _gcd_import
>   File "", line 961, in _find_and_load
>   File "", line 950, in
> _find_and_load_unlocked
>   File "", line 655, in _load_unlocked
>   File "", line 678, in exec_module
>   File "", line 205, in
> _call_with_frames_removed
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/contrib/auth/models.py", line 4, in 
> from django.contrib.auth.base_user import AbstractBaseUser,
> BaseUserManager
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/contrib/auth/base_user.py", line 52, in 
> class AbstractBaseUser(models.Model):
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/models/base.py", line 119, in __new__
> new_class.add_to_class('_meta', Options(meta, app_label))
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/models/base.py", line 316, in add_to_class
> value.contribute_to_class(cls, name)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/models/options.py", line 214, in contribute_to_class
> self.db_table = truncate_name(self.db_table,
> connection.ops.max_name_length())
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/__init__.py", line 33, in __getattr__
> return getattr(connections[DEFAULT_DB_ALIAS], item)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/utils.py", line 211, in __getitem__
> backend = load_backend(db['ENGINE'])
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/db/utils.py", line 115, in load_backend
> return import_module('%s.base' % backend_name)
>   File
> "/Users/lyle/.virtualenvs/project/lib/python3.6/importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/contrib/gis/db/backends/postgis/base.py", line 5, in
> 
> from .features import DatabaseFeatures
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> packages/django/contrib/gis/db/backends/postgis/features.py", line 1, in
> 
> from django.contrib.gis.db.backends.base.features import
> BaseSpatialFeatures
>   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
> 

[Django] #28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2 4d2925d6"

2017-07-28 Thread Django
#28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2
4d2925d6"
-+-
   Reporter:  Lyle   |  Owner:  nobody
  Scott III  |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  GIS|Version:  1.10
   Severity:  Normal |   Keywords:  geos version
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I updated Python via brew yesterday (3.6.1 to 3.6.2) and have been having
 problems running Django since then.
 https://code.djangoproject.com/ticket/28441 references the issue, but for
 Django 1.11.x. Looking at the PR for that ticket,
 https://github.com/django/django/pull/8817, it looks like that is not a
 clean patch to Django 1.10.x

 * macOS Sierra - 10.12.5 (16F73)
 * Homebrew 1.2.5
 * Python 3.6.2 from brew

 {{{
 Traceback (most recent call last):
   File "gooee_django/manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/core/management/__init__.py", line 341, in execute
 django.setup()
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/__init__.py", line 27, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/apps/registry.py", line 108, in populate
 app_config.import_models(all_models)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/apps/config.py", line 199, in import_models
 self.models_module = import_module(models_module_name)
   File
 "/Users/lyle/.virtualenvs/project/lib/python3.6/importlib/__init__.py",
 line 126, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 978, in _gcd_import
   File "", line 961, in _find_and_load
   File "", line 950, in
 _find_and_load_unlocked
   File "", line 655, in _load_unlocked
   File "", line 678, in exec_module
   File "", line 205, in
 _call_with_frames_removed
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/auth/models.py", line 4, in 
 from django.contrib.auth.base_user import AbstractBaseUser,
 BaseUserManager
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/auth/base_user.py", line 52, in 
 class AbstractBaseUser(models.Model):
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/models/base.py", line 119, in __new__
 new_class.add_to_class('_meta', Options(meta, app_label))
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/models/base.py", line 316, in add_to_class
 value.contribute_to_class(cls, name)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/models/options.py", line 214, in contribute_to_class
 self.db_table = truncate_name(self.db_table,
 connection.ops.max_name_length())
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/__init__.py", line 33, in __getattr__
 return getattr(connections[DEFAULT_DB_ALIAS], item)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/utils.py", line 211, in __getitem__
 backend = load_backend(db['ENGINE'])
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/db/utils.py", line 115, in load_backend
 return import_module('%s.base' % backend_name)
   File
 "/Users/lyle/.virtualenvs/project/lib/python3.6/importlib/__init__.py",
 line 126, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/gis/db/backends/postgis/base.py", line 5, in
 
 from .features import DatabaseFeatures
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/gis/db/backends/postgis/features.py", line 1, in
 
 from django.contrib.gis.db.backends.base.features import
 BaseSpatialFeatures
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/gis/db/backends/base/features.py", line 4, in
 
 from django.contrib.gis.db.models import aggregates
   File "/Users/lyle/.virtualenvs/project/lib/python3.6/site-
 packages/django/contrib/gis/db/models/__init__.py", line 2, in 
 from 

Re: [Django] #28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2 4d2925d6"

2017-07-28 Thread Django
#28447: django.contrib.gis.geos can't parse version string "3.6.2-CAPI-1.10.2
4d2925d6"
-+-
 Reporter:  Lyle Scott III   |Owner:  Lyle
 Type:   |  Scott III
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  geos version | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Lyle Scott III):

 * owner:  nobody => Lyle Scott III
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1a6040ddd891757888d10bddcdb13abc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.

2017-07-28 Thread Django
#27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.
-+-
 Reporter:  Jarek Glowacki   |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql None NULL| Triage Stage:  Accepted
  transform  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * status:  new => assigned
 * owner:  (none) => Sergey Fedoseev


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.dea0a27b73fceb4955bb2ac6dbf34aeb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #28446: QuerySet.extra is required for using SQL functions in SELECT clause

2017-07-28 Thread Django
#28446: QuerySet.extra is required for using SQL functions in SELECT clause
-+-
   Reporter:  chuck- |  Owner:  nobody
  horowitz   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  QuerySet.extra
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In this case, I have a table that is indexed and queried based on long
 integer IP addresses.  My QuerySet will ultimately be passed along to a
 serializer expecting an IPAddressField compatible item however, which must
 be a valid IPv4 string.  So I would like SQL that looks like:

 {{{
 SELECT INET_NTOA(iplong) AS ip, COUNT(*) AS count FROM ipTable  GROUP BY
 INET_NTOA(iplong) ORDER BY count DESC;
 }}}

 To do this with ORM and QuerySet.extra() looks like:

 {{{
 Model.extra(select={'ip':
 
'INET_NTOA(iplong)'}).values('ip').annotate(count=Count('*')).order_by('-count')
 }}}

 This is not a problem for my application, but I wanted to pass this along
 as requested in the documentation.  Additionally, perhaps there is a
 better/more idomatic way of doing this (not requiring QuerySet.extra())
 that you might be able to point me towards.

 Thanks for making a great framework!

 Best,
 Chuck

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.94bdff09be8fff2c52dface85fe6c8d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28444: Allow for different settings for each thread when testing with --parallel

2017-07-28 Thread Django
#28444: Allow for different settings for each thread when testing with 
--parallel
---+--
 Reporter:  Leonardo Arroyo|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.11
 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 Simon Charette):

 I can't find the exact discussion (either here or on the mailing list) but
 this was discussed in the past. I think it was about using a different
 Redis databases per-process which is really similar to this issue.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.10bd5344d0998f4b355d8c5bd3adb564%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28446: QuerySet.extra is required for using SQL functions in SELECT clause

2017-07-28 Thread Django
#28446: QuerySet.extra is required for using SQL functions in SELECT clause
-+-
 Reporter:  Chuck Horowitz   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Charles Horowitz):

 Okay great!  I will adjust my code to make use of Func and F come Monday.
 Thanks a million for the quick and helpful response!  I love Django!  Feel
 free to close this ticket

 Thanks again all,
 Best,
 Chuck

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.077c9e3d4d1da9c8d4e00538161cac59%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28446: QuerySet.extra is required for using SQL functions in SELECT clause

2017-07-28 Thread Django
#28446: QuerySet.extra is required for using SQL functions in SELECT clause
-+-
 Reporter:  Chuck Horowitz   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 Hello Chuck,

 You should be able to use `Func`
 [https://docs.djangoproject.com/en/1.11/ref/models/expressions/#func-
 expressions for this purpose].

 {{{#!python
 from django.db import models
 from django.db.models import Func, F

 Model.objects.annotate(
ip=Func(F('iplong'), function='INET_NTOA',
 output_field=models.CharField(max_length=15)),
 ).values('ip').annotate(count=Count('*')).order_by('-count')
 }}}

 You can even define your own `Func` subclass and use it instead.

 {{{#!python
 class INetNTOA(Func):
function = 'INET_NTOA'
output_field = models.CharField(max_length=15)

 Model.objects.annotate(
ip=INetNTOA(F('iplong')),
 ).values('ip').annotate(count=Count('*')).order_by('-count')
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.4805b2b18239e82ec45a65bf6104f9aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28445: DateField timezone issue with get_or_create (duplicate key value violates unique constraint)

2017-07-28 Thread Django
#28445: DateField timezone issue with get_or_create (duplicate key value 
violates
unique constraint)
-+-
 Reporter:  Jure Erznožnik   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  orm timezone | Triage Stage:
  get_or_create  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jure Erznožnik):

 Removing auto_now=True solved the problem.
 I still don't see how that IS the solution: I WAS using now() for date in
 searc / create. auto_now should make o difference.
 Thanks for the suggestion.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.18f1495153c60005ebb8437cd76b272e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.