[Django] #27263: Don't apply the rest of validators if the first one failed

[Django]

#27263: Don't apply the rest of validators if the first one failed
-+-
 Reporter:  Alexey Rogachev  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  master
 Severity:  Normal   |   Keywords:  form, validator
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I have a couple of validators for files, `FileSizeValidator` and
 `FileTypeValidator`.

 I attach it to form field like this:

 {{{#!python
 class ChartForm(forms.ModelForm):
 import_file = forms.FileField(required=False, label='File for import',
 validators = [
 FileSizeValidator(max_size='500 kb'),
 FileTypeValidator(extensions=('xlsx',))
 ])
 }}}

 Validators are extended from `object` and implement `__init__` and
 `__call__` methods (latter raises `ValidationError`).

 The problem is, when I load the bigger file and with different extension,
 both validators execute and both error messages are shown for field (about
 exceeding max limit and wrong extension).

 What I want - if first validator failed, don't even apply the rest of
 validators. For this specific scenario is not crucial, but in case of
 bigger amount of validators and more complex checks it can be a problem.
 For example if we need to read the file and verify that something exists
 there, why whe should do that if it's a size limit already exceeded.

 Another option can be customizing each validator to not execute in case of
 existing errors.

 I tried to add additional `field` argument to validator:

 {{{#!python
 class FileSizeValidator(object):
 def __init__(self, max_size, field=None):
 self.max_size = max_size
 self.field = field
 }}}

 and pass it in form's `__init __` method:

 {{{#!python
 class ChartForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(ChartForm, self).__init__(*args, **kwargs)
 for validator in self.fields['import_file'].validators:
 validator.form = self.fields['import_file']
 }}}

 but I don't know how to properly call `self.field.clean()` which requires
 `data`. Besides that, this is not good approach, because some other
 validators (for example from Django core) can be attached to field.

 Also this will require creating some additional mixin that must be
 attached along with validators.

 I think there is should be much simpler and elegant solution.

 Can't find related questions or info in docs.

--
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/052.cae69e187e0aaa0730802f8486410d55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27263: Don't apply the rest of validators if the first one failed

[Django]

#27263: Don't apply the rest of validators if the first one failed
-+--
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, validator  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Alexey Rogachev):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> I have a couple of validators for files, `FileSizeValidator` and
> `FileTypeValidator`.
>
> I attach it to form field like this:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> import_file = forms.FileField(required=False, label='File for import',
> validators = [
> FileSizeValidator(max_size='500 kb'),
> FileTypeValidator(extensions=('xlsx',))
> ])
> }}}
>
> Validators are extended from `object` and implement `__init__` and
> `__call__` methods (latter raises `ValidationError`).
>
> The problem is, when I load the bigger file and with different extension,
> both validators execute and both error messages are shown for field
> (about exceeding max limit and wrong extension).
>
> What I want - if first validator failed, don't even apply the rest of
> validators. For this specific scenario is not crucial, but in case of
> bigger amount of validators and more complex checks it can be a problem.
> For example if we need to read the file and verify that something exists
> there, why whe should do that if it's a size limit already exceeded.
>
> Another option can be customizing each validator to not execute in case
> of existing errors.
>
> I tried to add additional `field` argument to validator:
>
> {{{#!python
> class FileSizeValidator(object):
> def __init__(self, max_size, field=None):
> self.max_size = max_size
> self.field = field
> }}}
>
> and pass it in form's `__init __` method:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> def __init__(self, *args, **kwargs):
> super(ChartForm, self).__init__(*args, **kwargs)
> for validator in self.fields['import_file'].validators:
> validator.form = self.fields['import_file']
> }}}
>
> but I don't know how to properly call `self.field.clean()` which requires
> `data`. Besides that, this is not good approach, because some other
> validators (for example from Django core) can be attached to field.
>
> Also this will require creating some additional mixin that must be
> attached along with validators.
>
> I think there is should be much simpler and elegant solution.
>
> Can't find related questions or info in docs.

New description:

 I have a couple of validators for files, `FileSizeValidator` and
 `FileTypeValidator`.

 I attach it to form field like this:

 {{{#!python
 class ChartForm(forms.ModelForm):
 import_file = forms.FileField(required=False, label='File for import',
 validators = [
 FileSizeValidator(max_size='500 kb'),
 FileTypeValidator(extensions=('xlsx',))
 ])
 }}}

 Validators are extended from `object` and implement `__init__` and
 `__call__` methods (latter raises `ValidationError`).

 The problem is, when I load the bigger file and with different extension,
 both validators execute and both error messages are shown for field (about
 exceeding max limit and wrong extension).

 What I want - if first validator failed, don't even apply the rest of
 validators. For this specific scenario is not crucial, but in case of
 bigger amount of validators and more complex checks it can be a problem.
 For example if we need to read the file and verify that something exists
 there, why whe should do that if it's a size limit already exceeded.

 Another option can be customizing each validator to not execute in case of
 existing errors.

 I tried to add additional `field` argument to validator:

 {{{#!python
 class FileSizeValidator(object):
 def __init__(self, max_size, field=None):
 self.max_size = max_size
 self.field = field
 }}}

 and pass it in form's `__init __` method:

 {{{#!python
 class ChartForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(ChartForm, self).__init__(*args, **kwargs)
 for validator in self.fields['import_file'].validators:
 validator.form = self.fields['import_file']
 }}}

 but I don't know how to properly call `self.field.clean()` which requires
 `data`. Besides that, this is not good approach, because some other
 validators (for example from Django core) can be attached to field.

 Also this will require creating some a

Re: [Django] #27263: Don't apply the rest of validators if the first one failed

[Django]

#27263: Don't apply the rest of validators if the first one failed
-+--
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, validator  | 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 Alexey Rogachev:

Old description:

> I have a couple of validators for files, `FileSizeValidator` and
> `FileTypeValidator`.
>
> I attach it to form field like this:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> import_file = forms.FileField(required=False, label='File for
> import', validators = [
> FileSizeValidator(max_size='500 kb'),
> FileTypeValidator(extensions=('xlsx',))
> ])
> }}}
>
> Validators are extended from `object` and implement `__init__` and
> `__call__` methods (latter raises `ValidationError`).
>
> The problem is, when I load the bigger file and with different extension,
> both validators execute and both error messages are shown for field
> (about exceeding max limit and wrong extension).
>
> What I want - if first validator failed, don't even apply the rest of
> validators. For this specific scenario is not crucial, but in case of
> bigger amount of validators and more complex checks it can be a problem.
> For example if we need to read the file and verify that something exists
> there, why whe should do that if it's a size limit already exceeded.
>
> Another option can be customizing each validator to not execute in case
> of existing errors.
>
> I tried to add additional `field` argument to validator:
>
> {{{#!python
> class FileSizeValidator(object):
> def __init__(self, max_size, field=None):
> self.max_size = max_size
> self.field = field
> }}}
>
> and pass it in form's `__init __` method:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> def __init__(self, *args, **kwargs):
> super(ChartForm, self).__init__(*args, **kwargs)
> for validator in self.fields['import_file'].validators:
> validator.form = self.fields['import_file']
> }}}
>
> but I don't know how to properly call `self.field.clean()` which requires
> `data`. Besides that, this is not good approach, because some other
> validators (for example from Django core) can be attached to field.
>
> Also this will require creating some additional mixin that must be
> attached along with validators.
>
> I think there is should be much simpler and elegant solution.
>
> Can't find related questions or info in docs.

New description:

 I have a couple of validators for files, `FileSizeValidator` and
 `FileTypeValidator`.

 I attach it to form field like this:

 {{{#!python
 class ChartForm(forms.ModelForm):
 import_file = forms.FileField(required=False, label='File for import',
 validators = [
 FileSizeValidator(max_size='500 kb'),
 FileTypeValidator(extensions=('xlsx',))
 ])
 }}}

 Validators are extended from `object` and implement `__init__` and
 `__call__` methods (latter raises `ValidationError`).

 The problem is, when I load the bigger file and with different extension,
 both validators execute and both error messages are shown for field (about
 exceeding max limit and wrong extension).

 What I want - if first validator failed, don't even apply the rest of
 validators. For this specific scenario is not crucial, but in case of
 bigger amount of validators and more complex checks it can be a problem.
 For example if we need to read the file and verify that something exists
 there, why whe should do that if a size limit already exceeded.

 Another option can be customizing each validator to not execute in case of
 existing errors.

 I tried to add additional `field` argument to validator:

 {{{#!python
 class FileSizeValidator(object):
 def __init__(self, max_size, field=None):
 self.max_size = max_size
 self.field = field
 }}}

 and pass it in form's `__init __` method:

 {{{#!python
 class ChartForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(ChartForm, self).__init__(*args, **kwargs)
 for validator in self.fields['import_file'].validators:
 validator.form = self.fields['import_file']
 }}}

 but I don't know how to properly call `self.field.clean()` which requires
 `data`. Besides that, this is not good approach, because some other
 validators (for example from Django core) can be attached to field.

 Also this will require creating some additional mixin that must be
 attached along with valida

Re: [Django] #27263: Don't apply the rest of validators if the first one failed

[Django]

#27263: Don't apply the rest of validators if the first one failed
-+--
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, validator  | 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 Alexey Rogachev:

Old description:

> I have a couple of validators for files, `FileSizeValidator` and
> `FileTypeValidator`.
>
> I attach it to form field like this:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> import_file = forms.FileField(required=False, label='File for
> import', validators = [
> FileSizeValidator(max_size='500 kb'),
> FileTypeValidator(extensions=('xlsx',))
> ])
> }}}
>
> Validators are extended from `object` and implement `__init__` and
> `__call__` methods (latter raises `ValidationError`).
>
> The problem is, when I load the bigger file and with different extension,
> both validators execute and both error messages are shown for field
> (about exceeding max limit and wrong extension).
>
> What I want - if first validator failed, don't even apply the rest of
> validators. For this specific scenario is not crucial, but in case of
> bigger amount of validators and more complex checks it can be a problem.
> For example if we need to read the file and verify that something exists
> there, why whe should do that if a size limit already exceeded.
>
> Another option can be customizing each validator to not execute in case
> of existing errors.
>
> I tried to add additional `field` argument to validator:
>
> {{{#!python
> class FileSizeValidator(object):
> def __init__(self, max_size, field=None):
> self.max_size = max_size
> self.field = field
> }}}
>
> and pass it in form's `__init __` method:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> def __init__(self, *args, **kwargs):
> super(ChartForm, self).__init__(*args, **kwargs)
> for validator in self.fields['import_file'].validators:
> validator.form = self.fields['import_file']
> }}}
>
> but I don't know how to properly call `self.field.clean()` which requires
> `data`. Besides that, this is not good approach, because some other
> validators (for example from Django core) can be attached to field.
>
> Also this will require creating some additional mixin that must be
> attached along with validators.
>
> I think there is should be much simpler and elegant solution.
>
> Can't find related questions or info in docs.

New description:

 I have a couple of validators for files, `FileSizeValidator` and
 `FileTypeValidator`.

 I attach it to form field like this:

 {{{#!python
 class ChartForm(forms.ModelForm):
 import_file = forms.FileField(required=False, label='File for import',
 validators = [
 FileSizeValidator(max_size='500 kb'),
 FileTypeValidator(extensions=('xlsx',))
 ])
 }}}

 Validators are extended from `object` and implement `__init__` and
 `__call__` methods (latter raises `ValidationError`).

 The problem is, when I load the bigger file and with different extension,
 both validators execute and both error messages are shown for field (about
 exceeding max limit and wrong extension).

 What I want - if first validator failed, don't even apply the rest of
 validators. For this specific scenario is not crucial, but in case of
 bigger amount of validators and more complex checks it can be a problem.
 For example if we need to read the file and verify that something exists
 there, why whe should do that if a size limit already exceeded.

 Another option can be customizing each validator to not execute in case of
 existing errors.

 I tried to add additional `field` argument to validator:

 {{{#!python
 class FileSizeValidator(object):
 def __init__(self, max_size, field):
 self.max_size = max_size
 self.field = field
 }}}

 and pass it in form's `__init __` method:

 {{{#!python
 class ChartForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(ChartForm, self).__init__(*args, **kwargs)
 for validator in self.fields['import_file'].validators:
 validator.form = self.fields['import_file']
 }}}

 but I don't know how to properly call `self.field.clean()` which requires
 `data`. Besides that, this is not good approach, because some other
 validators (for example from Django core) can be attached to field.

 Also this will require creating some additional mixin that must be
 attached along with validators.

 I 

Re: [Django] #27263: Don't apply the rest of validators if the first one failed

[Django]

#27263: Don't apply the rest of validators if the first one failed
-+--
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, validator  | 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 Alexey Rogachev:

Old description:

> I have a couple of validators for files, `FileSizeValidator` and
> `FileTypeValidator`.
>
> I attach it to form field like this:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> import_file = forms.FileField(required=False, label='File for
> import', validators = [
> FileSizeValidator(max_size='500 kb'),
> FileTypeValidator(extensions=('xlsx',))
> ])
> }}}
>
> Validators are extended from `object` and implement `__init__` and
> `__call__` methods (latter raises `ValidationError`).
>
> The problem is, when I load the bigger file and with different extension,
> both validators execute and both error messages are shown for field
> (about exceeding max limit and wrong extension).
>
> What I want - if first validator failed, don't even apply the rest of
> validators. For this specific scenario is not crucial, but in case of
> bigger amount of validators and more complex checks it can be a problem.
> For example if we need to read the file and verify that something exists
> there, why whe should do that if a size limit already exceeded.
>
> Another option can be customizing each validator to not execute in case
> of existing errors.
>
> I tried to add additional `field` argument to validator:
>
> {{{#!python
> class FileSizeValidator(object):
> def __init__(self, max_size, field):
> self.max_size = max_size
> self.field = field
> }}}
>
> and pass it in form's `__init __` method:
>
> {{{#!python
> class ChartForm(forms.ModelForm):
> def __init__(self, *args, **kwargs):
> super(ChartForm, self).__init__(*args, **kwargs)
> for validator in self.fields['import_file'].validators:
> validator.form = self.fields['import_file']
> }}}
>
> but I don't know how to properly call `self.field.clean()` which requires
> `data`. Besides that, this is not good approach, because some other
> validators (for example from Django core) can be attached to field.
>
> Also this will require creating some additional mixin that must be
> attached along with validators.
>
> I think there is should be much simpler and elegant solution.
>
> Can't find related questions or info in docs.

New description:

 I have a couple of validators for files, `FileSizeValidator` and
 `FileTypeValidator`.

 I attach it to form field like this:

 {{{#!python
 class ChartForm(forms.ModelForm):
 import_file = forms.FileField(required=False, label='File for import',
 validators = [
 FileSizeValidator(max_size='500 kb'),
 FileTypeValidator(extensions=('xlsx',))
 ])
 }}}

 Validators are extended from `object` and implement `__init__` and
 `__call__` methods (latter raises `ValidationError`).

 The problem is, when I load the bigger file and with different extension,
 both validators execute and both error messages are shown for field (about
 exceeding max limit and wrong extension).

 What I want - if first validator failed, don't even apply the rest of
 validators. For this specific scenario is not crucial, but in case of
 bigger amount of validators and more complex checks it can be a problem.
 For example if we need to read the file and verify that something exists
 there, why whe should do that if a size limit already exceeded.

 Another option can be customizing each validator to not execute in case of
 existing errors.

 I tried to add additional `field` argument to validator:

 {{{#!python
 class FileSizeValidator(object):
 def __init__(self, max_size, field):
 self.max_size = max_size
 self.field = field
 }}}

 and pass it in form's `__init __` method:

 {{{#!python
 class ChartForm(forms.ModelForm):
 def __init__(self, *args, **kwargs):
 super(ChartForm, self).__init__(*args, **kwargs)
 for validator in self.fields['import_file'].validators:
 validator.form = self.fields['import_file']
 }}}

 but I don't know how to properly call `self.field.clean()` which requires
 `data`. Besides that, this is not good approach, because some other
 validators (for example from Django core) can be attached to field.

 Also this will require creating some additional mixin that must be
 attached along with validators.

 I think

Re: [Django] #27262: Delegate URL resolver checks to URL classes

[Django]

#27262: Delegate URL resolver checks to URL classes
+
 Reporter:  Sjoerd Job Postmus  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Core (URLs) |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by Alasdair Nicol):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * easy:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 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 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.12b5853e8f35356022f32362b62b0319%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23776: HStoreField example doesn't work

[Django]

#23776: HStoreField example doesn't work
-+-
 Reporter:  vedgar   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  postgres hstore  | Triage Stage:
  register   |  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
 * component:  Database layer (models, ORM) => Documentation
 * resolution:   => worksforme


Comment:

 That step is documented, "Setup the hstore extension in PostgreSQL before
 the first CreateModel or AddField operation by adding a migration with the
 HStoreExtension operation. "

--
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.dee214b98e23c89073c33ac3ca191b50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27262: Delegate URL resolver checks to URL classes

[Django]

#27262: Delegate URL resolver checks to URL classes
--+
 Reporter:  Sjoerd Job Postmus|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization


--
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.700fd6b747eac1f0df05978ef367e617%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27260: Performance Issue because of LEFT OUTER JOIN instead the better INNER JOIN

[Django]

#27260: Performance Issue because of LEFT OUTER JOIN instead the better INNER 
JOIN
-+-
 Reporter:  Sven R. Kunze|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I haven't worked with the ORM enough to know if changing the query
 operator is feasible.

--
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.709faaeca201fab17323d8a0fe7ae433%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27226: Remove patch_response_headers()'s setting of the "Last-Modified" header (was: cache.patch_response_headers() adds ETag and Last-Modified to the response)

[Django]

#27226: Remove patch_response_headers()'s setting of the "Last-Modified" header
-+-
 Reporter:  Rinat Khabibiev  |Owner:  Rinat
 Type:   |  Khabibiev
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 The ETag removal will go through a deprecation in #26447 so this ticket is
 limited to removing the Last-Modified header. There's some discussion on
 the [https://github.com/django/django/pull/7247 PR] about whether or not
 removing it could result in behavior changes.

--
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.2afc3e9ca455b936b52e826e6035d917%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27264: Model Meta is overwriten by abstract parent class

[Django]

#27264: Model Meta is overwriten by abstract parent class
-+-
 Reporter:  luxcem   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models meta  | Triage Stage:
  inheritance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by luxcem):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> Hi, it seems to be an actual django bug, the example at the address
> https://docs.djangoproject.com/en/1.10/topics/db/models/#meta-inheritance
> does not work correctly,
>
> from django.db import models
>
> class BaseCategory(models.Model):
> title = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
> ordering = ['title']
>
> class Category(BaseCategory):
>
> name = models.CharField(max_length=100)
>
> class Meta(BaseCategory.Meta):
> ordering = ['name']
> db_table = 'samble'
>
> Category.Meta.ordering is equal to ['title'], Category.Meta.db_table is
> undefined and Category.Meta.abstract is correctly set to false, in fact
> Category.Meta is of type BaseCategory.Meta.
>
> A stranger behavior is when `abstract = True` is added to the subclass :
>
> class Category(BaseCategory):
>
> name = models.CharField(max_length=100)
>
> class Meta(BaseCategory.Meta):
> abstract = True
> ordering = ['name']
> db_table = 'sample'
>
> Now the behavior is correct (if abstract was not set) :
> Category.Meta.db_table = 'sample', Category.Meta.ordering = ['name'] but
> Category.Meta.abstract = False, Category.Meta is of type Category.Meta
>
> So additionally it is impossible to create an abstract class inheriting
> an abstract class.
>
> Tested with django 1.8, 1.9, 1.10, 1.10.1 and python 2.7, 3.4

New description:

 Hi, it seems to be an actual django bug, the example at the address
 https://docs.djangoproject.com/en/1.10/topics/db/models/#meta-inheritance
 does not work correctly,


 {{{
   from django.db import models

 class BaseCategory(models.Model):
 title = models.CharField(max_length=100)

 class Meta:
 abstract = True
 ordering = ['title']

 class Category(BaseCategory):

 name = models.CharField(max_length=100)

 class Meta(BaseCategory.Meta):
 ordering = ['name']
 db_table = 'samble'
 }}}


 Category.Meta.ordering is equal to ['title'], Category.Meta.db_table is
 undefined and Category.Meta.abstract is correctly set to false, in fact
 Category.Meta is of type BaseCategory.Meta.

 A stranger behavior is when `abstract = True` is added to the subclass :


 {{{
   class Category(BaseCategory):

 name = models.CharField(max_length=100)

 class Meta(BaseCategory.Meta):
 abstract = True
 ordering = ['name']
 db_table = 'sample'

 }}}

 Now the behavior is correct (if abstract was not set) :
 Category.Meta.db_table = 'sample', Category.Meta.ordering = ['name'] but
 Category.Meta.abstract = False, Category.Meta is of type Category.Meta

 So additionally it is impossible to create an abstract class inheriting
 an abstract class.

 Tested with django 1.8, 1.9, 1.10, 1.10.1 and python 2.7, 3.4

--

--
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.418a5363bed14ec7b6cf07fed3fb8130%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27264: Model Meta is overwriten by abstract parent class

[Django]

#27264: Model Meta is overwriten by abstract parent class
--+
 Reporter:  luxcem|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:  models meta
  |  inheritance
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hi, it seems to be an actual django bug, the example at the address
 https://docs.djangoproject.com/en/1.10/topics/db/models/#meta-inheritance
 does not work correctly,

 from django.db import models

 class BaseCategory(models.Model):
 title = models.CharField(max_length=100)

 class Meta:
 abstract = True
 ordering = ['title']

 class Category(BaseCategory):

 name = models.CharField(max_length=100)

 class Meta(BaseCategory.Meta):
 ordering = ['name']
 db_table = 'samble'

 Category.Meta.ordering is equal to ['title'], Category.Meta.db_table is
 undefined and Category.Meta.abstract is correctly set to false, in fact
 Category.Meta is of type BaseCategory.Meta.

 A stranger behavior is when `abstract = True` is added to the subclass :

 class Category(BaseCategory):

 name = models.CharField(max_length=100)

 class Meta(BaseCategory.Meta):
 abstract = True
 ordering = ['name']
 db_table = 'sample'

 Now the behavior is correct (if abstract was not set) :
 Category.Meta.db_table = 'sample', Category.Meta.ordering = ['name'] but
 Category.Meta.abstract = False, Category.Meta is of type Category.Meta

 So additionally it is impossible to create an abstract class inheriting
 an abstract class.

 Tested with django 1.8, 1.9, 1.10, 1.10.1 and python 2.7, 3.4

--
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/049.19f2c2b15ef9e7901cb4f0c8e6784115%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27263: Allow validators to short-circuit in form field validation (was: Don't apply the rest of validators if the first one failed)

[Django]

#27263: Allow validators to short-circuit in form field validation
-+-
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form, validator  | Triage Stage:  Someday/Maybe
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 => Someday/Maybe


Comment:

 I think the idea makes sense but I'm not sure about a suitable API. If you
 have a design proposal, please share it on the DevelopersMailingList to
 get feedback.

--
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.3de65d541175af946746458e0f8a0065%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #6517: MySQL: manage.py dbshell does not get charset from DATABASES setting

[Django]

#6517: MySQL: manage.py dbshell does not get charset from DATABASES setting
-+-
 Reporter:  Tom Vergote  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  assigned => new
 * owner:  Victoria Martínez de la Cruz => (none)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/062.94cabdc6750bdc28866496e75176756a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27249: IntegrityError when using ManyToManyField.add() with a value of incorrect type

[Django]

#27249: IntegrityError when using ManyToManyField.add() with a value of 
incorrect
type
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  manytomanyfield, | Triage Stage:  Accepted
  integrityerror |
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:   => duplicate


Comment:

 Duplicate of #8467.

--
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.298c6e73a6f368ee4ccf07d21be46a9b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #8467: For ManyToMany manager, we should convert objects being added or removed to the pk type if they are not.

[Django]

#8467: For ManyToMany manager, we should convert objects being added or removed 
to
the pk type if they are not.
-+-
 Reporter:  Wonlay   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Duplicate entry, | Triage Stage:  Accepted
  add, remove, ManyToManyField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 As noted in duplicate #27249, calling `Field.to_python()` on the input
 might work.

--
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.3d8a4775f6da2fbb0f612f36542cf96b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16487: F expression with timedelta does not work with __range query filter

[Django]

#16487: F expression with timedelta does not work with __range query filter
-+-
 Reporter:  Ben Davis|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (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):

 * cc: Matthew Wilkes (added)


Comment:

 Looks like #22288 fixed this. Matthew, do you think we should a test for
 this case or are the tests from 4f138fe5a496a81115c4fba6615a517fc62c3b17
 sufficient?

--
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/068.5b2116b1bb41872dbf84dc270eb5a8e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
-+-
 Reporter:  halturin |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  yandex-sprint| Triage Stage:  Accepted
  oracle session pool|
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  assigned => new
 * owner:  Matt Boersma => (none)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/066.ef058f3395527895182fec6f7c81c4ba%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13240: Modify RelatedManager and ManyRelatedManager add() and remove() to accept QuerySets and iterables

[Django]

#13240: Modify RelatedManager and ManyRelatedManager add() and remove() to 
accept
QuerySets and iterables
-+-
 Reporter:  Gabriel Hurley   |Owner:  (none)
 Type:  New feature  |   Status:  new
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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * owner:  Gabriel Hurley => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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/071.19d296a040b3aeb341a547d6571e66bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #13161: Avoid global registration of psycopg2 adapters/extensions

[Django]

#13161: Avoid global registration of psycopg2 adapters/extensions
-+-
 Reporter:  spoksss  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  psycopg2, unicode| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 The unicode type registration will be dropped with Python 2. There are
 some
 
[https://github.com/django/django/blob/cecef94275118dc49a1b0d89d3ca9734e2ec9776/django/db/backends/postgresql/base.py#L50-L65
 other extensions/types registered] but I'm not sure they're causing any
 problems. Feel free to reopen if someone sees a reason to change things
 here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.3bd9b7d638f673026277b80521307e19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14357: Prevent innapropriate order-based grouping on values+annotate queries

[Django]

#14357: Prevent innapropriate order-based grouping on values+annotate queries
-+-
 Reporter:  Martin Chase |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Simon Charette (added)


Comment:

 Simon, do you have any opinions about this change given we abandoned the
 idea of "Django 2.0" with large backwards incompatible changes? Not sure
 if a deprecation path to change the behavior is feasible.

--
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/070.47a4d16f99563cd821176abdb22c1532%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

[Django]

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
-+-
 Reporter:  Ian Kelly|Owner:  (none)
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Looks like a duplicate of #15844.

 (Fixed in Django 1.6 with 97774429aeb54df4c09895c07cd1b09e70201f7d and a
 test added in fa2e1e633ac2073906ed3f1f32107d02331107aa.)

--
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.dcf4f9177b92ca1e25a6e6fa537e918c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14357: Prevent innapropriate order-based grouping on values+annotate queries

[Django]

#14357: Prevent innapropriate order-based grouping on values+annotate queries
-+-
 Reporter:  Martin Chase |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I think we could and should make this change as it really common pitfall
 but it should follow a deprecation path.

 I've personally stopped using `ordering` because of its unexpected
 interaction with `distinct()` and `values()` for grouping by.

 The deprecation path should detect when `values()` is used for grouping on
 a queryset where the only defined ordering is from `_meta.ordering` in the
 SQL compiling step and raise a deprecation warning saying such ordering
 will be ignored in future version of Django.

--
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/070.61b879c625ed4bd9eedca0629c1ebc8a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14357: Prevent innapropriate order-based grouping on values+annotate queries

[Django]

#14357: Prevent innapropriate order-based grouping on values+annotate queries
-+-
 Reporter:  Martin Chase |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I think we should go as far as requiring all ordering clauses to be
 explicitly specified through `values()` when used to group by.

 For example, in the following case

 `Foo.objects.order_by('name').values('type').annotate(Count('name'))`

 A deprecation warning would be raised to notify the user that `'name'`
 won't automatically be added to `values()` in future Django version where
 the previous queryset would be equivalent to the following:

 `Foo.objects.values('type').annotate(Count('name'))`

 and the current behaviour could be preserved by adding `'name'` to
 `values()`:

 `Foo.objects.order_by('name').values('type',
 'name').annotate(Count('name'))`

 I haven't tested it myself to see if it's already the case but we should
 also disallow ordering by a non-grouped column or aggregate alias.

 `Foo.objects.values('type').annotate(Count('name')).order_by('name')`
 should raise a value error on the `order_by('name')` call.

--
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/070.b1396c53abdbbd6172922849885e426f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25049: Oracle fails to change unique_together constraints due to case sensitivity (was: Oracle constraints case sensitivity)

[Django]

#25049: Oracle fails to change unique_together constraints due to case 
sensitivity
-+-
 Reporter:  Pogsquog |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  Oracle constraints   | Triage Stage:  Accepted
  migration case |
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
 * component:  Database layer (models, ORM) => Migrations
 * resolution:   => duplicate


Comment:

 Confirmed that #26833 fixed this.

--
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/066.319cb9f66782dec78af8495106e7441a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27261: Missing python-brace-format marker for a contrib.admin string (was: Mismatch for placholders in japanese translations (django.contrib.admin app))

[Django]

#27261: Missing python-brace-format marker for a contrib.admin string
-+-
 Reporter:  Maxime Vdb   |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  translation  | Triage Stage:  Accepted
  japanese admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Claude Paroz):

 * status:  new => assigned
 * owner:  nobody => Claude Paroz
 * stage:  Unreviewed => Accepted


Comment:

 As Tim said, you should fix the string on Transifex.
 However, this reveals a bug in that the offended original string misses
 the `#, python-brace-format` marker in the base
 `en/LC_MESSAGES/django.po`. I'll fix that.
 With the proper marker, this error should have been caught by the gettext
 check program (msgfmt -vc).

--
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/063.1e7e54cbb84604d7764795d1fb0da048%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27261: Missing python-brace-format marker for a contrib.admin string

[Django]

#27261: Missing python-brace-format marker for a contrib.admin string
-+-
 Reporter:  Maxime Vdb   |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  translation  | Triage Stage:  Accepted
  japanese admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"2c501203601c9610e69155c57bfe235f155344e2" 2c50120]:
 {{{
 #!CommitTicketReference repository=""
 revision="2c501203601c9610e69155c57bfe235f155344e2"
 Fixed #27261 -- Added missing python-brace-format marker

 Thanks Maxime Vdb for the 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 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/063.27beba361bed23506132366a959d7e03%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27261: Missing python-brace-format marker for a contrib.admin string

[Django]

#27261: Missing python-brace-format marker for a contrib.admin string
-+-
 Reporter:  Maxime Vdb   |Owner:  Claude
 |  Paroz
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  translation  | Triage Stage:  Accepted
  japanese admin |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Claude Paroz ):

 In [changeset:"90949a156a2a7b67b52db4b2b53776a7016fda09" 90949a15]:
 {{{
 #!CommitTicketReference repository=""
 revision="90949a156a2a7b67b52db4b2b53776a7016fda09"
 [1.10.x] Fixed #27261 -- Added missing python-brace-format marker

 Thanks Maxime Vdb for the report.
 Backport of 2c501203601c9610e69155c57bfe235f155344e2 from master.
 }}}

--
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/063.8c495d223e3ffc5d835543653a87e8fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27264: Model Meta is overwriten by abstract parent class

[Django]

#27264: Model Meta is overwriten by abstract parent class
-+-
 Reporter:  luxcem   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models meta  | Triage Stage:
  inheritance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Django uses values from the process meta, e.g. `Category._meta.db_table`,
 not `Category.Meta`. Could you be more specific about the problems you
 encounter when using the models?

--
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.5fe23f2248fa152e4c348062d28ae905%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27258: Context processors are not called when using RequestContext and Django templates

[Django]

#27258: Context processors are not called when using RequestContext and Django
templates
-+--
 Reporter:  Andi Albrecht|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.10
 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
-+--
Changes (by Tim Graham):

 * cc: Aymeric Augustin (added)


Comment:

 Maybe the patch you suggested would be reasonable. One possibility for
 confusion would be if `template.backends.django.Template.render()`
 receives both a `RequestContext` and a `request`. Perhaps an error would
 need to be raised in that cause since `request` would be ignored.

 Any thoughts, Aymeric?

--
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/070.ff4a8f8bdae6a3c1b66c97ca20a9acad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27227: Full text search by UUIDField returns DataError

[Django]

#27227: Full text search by UUIDField returns DataError
-+-
 Reporter:  Dan Claudiu Pop  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  UUIDField fts| Triage Stage:
  postgres   |  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


--
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/071.6d9e4239fd3adbbad08d15e0419a5bf8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26010: I need to count objects in a queryset by year and month

[Django]

#26010: I need to count objects in a queryset by year and month
-+-
 Reporter:  Mahmood Khan |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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 Rich Rauenzahn):

 FYI:

 MonthTransform and YearTransform are gone now in Django 1.10.

 You can use TruncMonth/TrunchYear from django.db.models.functions.

 I believe it is slightly different -- I had to modify my html template to
 filter the value through |date: 'Y' and |date: 'm', otherwise I got
 something like "2016, midnight" rather than "2016"

 See:

 http://stackoverflow.com/questions/8746014/django-group-by-date-day-month-
 year
 https://code.djangoproject.com/ticket/26649
 https://docs.djangoproject.com/en/1.10/ref/models/database-
 functions/#trunc

--
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/069.bc4b70ca29c62bf087d1a91bc0f4da2e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24959: Allow using negative timedeltas in expressions (was: date_interval_sql Implementations for Database Backends Do Not Handle Negative timedelta Objects Properly)

[Django]

#24959: Allow using negative timedeltas in expressions
-+-
 Reporter:  Fred Palmer  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  date_interval_sql,   | Triage Stage:  Accepted
  timedelta, F, orm  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'm attaching the start of a regression test.

--
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/068.25f10712b16c3fa15a66f6708fb23ea9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24959: Allow using negative timedeltas in expressions

[Django]

#24959: Allow using negative timedeltas in expressions
-+-
 Reporter:  Fred Palmer  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  date_interval_sql,   | Triage Stage:  Accepted
  timedelta, F, orm  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * Attachment "24959-test.diff" 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/068.795ddbe166b79a3742a8351d676b4144%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27265: Using @admin.register causes failure when AdminModel constructor is overriden

[Django]

#27265: Using @admin.register causes failure when AdminModel constructor is
overriden
--+
 Reporter:  Diego Andrés Sanabria Martín  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.admin |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When trying to override the ModelAdmin constructor using the decorator
 @admin.register I get an exception.

 This is an example for a new project called "what" with an simple app
 "why":

 Commands to create the files (I used django 1.8.4):

 django-admin stratproject what
 cd what
 python manage.py startapp why

 what/settings.py
 {{{
 ...
 INSTALLED_APPS = (
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'why',
 )
 ...
 }}}

 why/models.py
 {{{
 from django.db import models

 # Create your models here.
 class WhyMe(models.Model):
 name = models.CharField(max_length=255)
 }}}

 why/admin.py
 {{{
 from django.contrib import admin

 from why.models import WhyMe

 @admin.register(WhyMe)
 class WhyMeAdmin(admin.ModelAdmin):
 def __init__(self, *args, **kwargs):
 super(WhyMeAdmin, self).__init__(*args, **kwargs)
 print("Wha???")
 }}}

 If I run the command 'runserver' I've got:
 {{{
 nhandled exception in thread started by 
 Traceback (most recent call last):
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/utils/autoreload.py", line 226, in wrapper
 fn(*args, **kwargs)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 113, in
 inner_run
 autoreload.raise_last_exception()
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/utils/autoreload.py", line 249, in raise_last_exception
 six.reraise(*_exception)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/utils/autoreload.py", line 226, in wrapper
 fn(*args, **kwargs)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/__init__.py", line 27, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/apps/registry.py", line 115, in populate
 app_config.ready()
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/contrib/admin/apps.py", line 23, in ready
 self.module.autodiscover()
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/contrib/admin/__init__.py", line 26, in autodiscover
 autodiscover_modules('admin', register_to=site)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/utils/module_loading.py", line 50, in autodiscover_modules
 import_module('%s.%s' % (app_config.name, module_to_search))
   File
 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File "/Users/diegueus9/.virtualenvs/django1.8/what/why/admin.py", line
 6, in 
 class WhyMeAdmin(admin.ModelAdmin):
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/contrib/admin/decorators.py", line 28, in
 _model_admin_wrapper
 admin_site.register(models, admin_class=admin_class)
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/django/contrib/admin/sites.py", line 108, in register
 admin_obj = admin_class(model, self)
   File "/Users/diegueus9/.virtualenvs/django1.8/what/why/admin.py", line
 8, in __init__
 super(WhyMeAdmin, self).__init__(*args, **kwargs)
 NameError: global name 'WhyMeAdmin' is not defined
 }}}

 However, if I use the normal registration 'admin.site.register(WhyMe,
 WhyMeAdmin)' everything works fine.
 This also happens with latest 1.8.x, 1.9.x and 1.10.x

--
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/052.15d2f7da9c4c407905f85df80de087eb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout

Re: [Django] #27265: Using @admin.register causes failure when AdminModel constructor is overriden

[Django]

#27265: Using @admin.register causes failure when AdminModel constructor is
overriden
-+-
 Reporter:  Diego Andrés |Owner:  nobody
  Sanabria Martín|
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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
-+-
Changes (by Diego Andrés Sanabria Martín):

 * needs_docs:   => 0
 * version:  1.10 => master
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Old description:

> When trying to override the ModelAdmin constructor using the decorator
> @admin.register I get an exception.
>
> This is an example for a new project called "what" with an simple app
> "why":
>
> Commands to create the files (I used django 1.8.4):
>
> django-admin stratproject what
> cd what
> python manage.py startapp why
>
> what/settings.py
> {{{
> ...
> INSTALLED_APPS = (
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> 'why',
> )
> ...
> }}}
>
> why/models.py
> {{{
> from django.db import models
>
> # Create your models here.
> class WhyMe(models.Model):
> name = models.CharField(max_length=255)
> }}}
>
> why/admin.py
> {{{
> from django.contrib import admin
>
> from why.models import WhyMe
>
> @admin.register(WhyMe)
> class WhyMeAdmin(admin.ModelAdmin):
> def __init__(self, *args, **kwargs):
> super(WhyMeAdmin, self).__init__(*args, **kwargs)
> print("Wha???")
> }}}
>
> If I run the command 'runserver' I've got:
> {{{
> nhandled exception in thread started by 
> Traceback (most recent call last):
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/utils/autoreload.py", line 226, in wrapper
> fn(*args, **kwargs)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/core/management/commands/runserver.py", line 113, in
> inner_run
> autoreload.raise_last_exception()
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/utils/autoreload.py", line 249, in raise_last_exception
> six.reraise(*_exception)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/utils/autoreload.py", line 226, in wrapper
> fn(*args, **kwargs)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/__init__.py", line 27, in setup
> apps.populate(settings.INSTALLED_APPS)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/apps/registry.py", line 115, in populate
> app_config.ready()
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/contrib/admin/apps.py", line 23, in ready
> self.module.autodiscover()
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/contrib/admin/__init__.py", line 26, in autodiscover
> autodiscover_modules('admin', register_to=site)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/utils/module_loading.py", line 50, in
> autodiscover_modules
> import_module('%s.%s' % (app_config.name, module_to_search))
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
> line 37, in import_module
> __import__(name)
>   File "/Users/diegueus9/.virtualenvs/django1.8/what/why/admin.py", line
> 6, in 
> class WhyMeAdmin(admin.ModelAdmin):
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/contrib/admin/decorators.py", line 28, in
> _model_admin_wrapper
> admin_site.register(models, admin_class=admin_class)
>   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
> packages/django/contrib/admin/sites.py", line 108, in register
> admin_obj = admin_class(model, self)
>   File "/Users/diegueus9/.virtualenvs/django1.8/what/why/admin.py", line
> 8, in __init__
> super(WhyMeAdmin, self).__init__(*args, **kwargs)
> NameError: global name 'WhyMeAdmin' is not defined
> }}}
>
> However, if I use the normal registration 'admin.site.register(WhyMe,
> WhyMeAdmin)' everything works fine.
> This also happens with latest 1.8.x, 1.9.x and 1.10.x

New description:

 When trying to override the ModelAdmin constructor using the decorator
 @admin.register I get an except

[Django] #27266: assertFormError fails when trying to check a custom validation in an Admin form

[Django]

#27266: assertFormError fails when trying to check a custom validation in an 
Admin
form
-+-
 Reporter:  Diego Andrés |  Owner:  nobody
  Sanabria Martín|
 Type:  Bug  | Status:  new
Component:  contrib.admin|Version:  master
 Severity:  Normal   |   Keywords:  unittest, admin,
 |  modelform, adminform, test
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 When using the assertFormError in a unittest to check a custome validation
 in an admin form the assertion fails because apparently the form in the
 admin view behaviours slightly different from a normal view.

 Create a project 'what' with an app 'why' (I used 1.8.4 but it was tested
 with master branch):

 django-admin startproject what
 cd what
 python manage.py startapp why

 Use this files to check the bug:

 what/settings.py
 {{{
 ...
 INSTALLED_APPS = (
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'why',
 )
 ...
 }}}

 why/models.py
 {{{
 from django.db import models

 # Create your models here.
 class WhyMe(models.Model):
 name = models.CharField(max_length=255)
 }}}

 why/admin.py
 {{{
 from django.contrib import admin
 from django.core.exceptions import ValidationError
 from django.forms import ModelForm

 from why.models import WhyMe

 class WhyMeAdminForm(ModelForm):
 def clean_name(self):
 name = self.cleaned_data['name']
 if name.startswith('xxx'):
 raise ValidationError('don\'t use xxx!', code='invalid')
 return name

 @admin.register(WhyMe)
 class WhyMeAdmin(admin.ModelAdmin):
 form = WhyMeAdminForm
 }}}

 why/tests.py
 {{{
 from django.contrib.auth.models import User
 from django.core.urlresolvers import reverse
 from django.test import TestCase

 class WhyMeAdminTest(TestCase):
 def setUp(self):
 self.user = User.objects.create_superuser(username='chuck',
 email='ch...@internet.com', password='no')
 self.client.login(username='chuck', password='no')

 def test_custome_validation(self):
 url = reverse('admin:why_whyme_add')
 data = {
 'name': 'xxxDiegueus9'
 }
 response = self.client.post(url, data, follow=True)

 self.assertEqual(response.status_code, 200)
 self.assertFormError(response, 'adminform', 'name', ['don\'t use
 xxx!'])
 }}}

 Finally run the tests and the result would be something like:
 {{{
 Creating test database for alias 'default'...
 E
 ==
 ERROR: test_custome_validation (why.tests.WhyMeAdminTest)
 --
 Traceback (most recent call last):
   File "/Users/diegueus9/.virtualenvs/django1.8/what/why/tests.py", line
 18, in test_custome_validation
 self.assertFormError(response, 'adminform', 'name', ['don\'t use
 xxx!'])
   File "/Users/diegueus9/.virtualenvs/django1.8/lib/python2.7/site-
 packages/Django-1.11.dev20160923192832-py2.7.egg/django/test/testcases.py",
 line 428, in assertFormError
 if field in context[form].errors:
 AttributeError: 'AdminForm' object has no attribute 'errors'

 --
 Ran 1 test in 0.771s

 FAILED (errors=1)
 Destroying test database for alias 'default'...
 }}}

 In the attached file I show that the validation works fine in the admin.
 I did a little of debug using ipdb and noticed that the errors are in
 'AdminForm.form.errors', perhaps it should be added a property to the
 AdminForm?
 This also fails using django 1.8.x, 1.9.x, 1.10.x

--
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/052.5f33531bf1e3e3fe6f7a5fd4ddb86f5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27266: assertFormError fails when trying to check a custom validation in an Admin form

[Django]

#27266: assertFormError fails when trying to check a custom validation in an 
Admin
form
-+-
 Reporter:  Diego Andrés Sanabria Martín |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.admin|Version:  master
 Severity:  Normal   | Resolution:
 Keywords:  unittest, admin, modelform,  |   Triage Stage:
  adminform, test|  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
Changes (by Diego Andrés Sanabria Martín):

 * Attachment "Screen Shot 2016-09-23 at 17.22.19.png" added.

 Custom validation in admin

--
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.9f4330ebc315446540e2129033756d62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27265: Using @admin.register causes failure when AdminModel constructor is overriden

[Django]

#27265: Using @admin.register causes failure when AdminModel constructor is
overriden
-+-
 Reporter:  Diego Andrés |Owner:  nobody
  Sanabria Martín|
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 It's a documented limitation: #24323.

--
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.cecb189ff48ae2edfdf7c04920e987db%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20939: Convert QuerySet to Query when filtering

[Django]

#20939: Convert QuerySet to Query when filtering
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by Tim Graham):

 I rebased and updated this to see if it's still worth doing and to learn
 something in the process. It's still incomplete and tests aren't passing:
 [https://github.com/django/django/pull/7289 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 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/066.aa3e9f149894891bcf4c5550f744c6f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.