date:20150323

Re: [Django] #24497: Truncation of microseconds in DateTimeField leads to lookup trouble

2015-03-23 Thread Django

Comment (by riklaunim):

Replying to [comment:2 claudep]:
> It might be a use case for the `supports_microseconds` widget property
(which needs documentation, by the way).
>
> Could you try to subclass `HiddenInput`, set `supports_microseconds`
class attribute to True for your subclass, and then use that widget in
your form?

Depends what should be the default behavior for a ModelForm? Field in a
model should be tailored to a matching form field and it validation rules.
If Django must permanently modify DatetTimes for display and alike
purposes then it should be explicit and consistent with models. If form
field has supports_microseconds then maybe DateTimeField in a model should
also have such attribute so that setting timezone.now()/datetime.now()
etc. won't save with microseconds in the first place?

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

[Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:   |  Owner:  nobody
  SimonSteinberger   |
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.8rc1
 Severity:  Release blocker  |   Keywords:  migrations, fail, collision
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Using an AbstractUser based user model with Django 1.8 RC1 causes the
 management command to create the database table layout to fail: "python
 manage.py migrate"

 Traceback:
 File "manage.py", line 9, in 
 execute_from_command_line(sys.argv)
 File "...\site-packages\django\core\management\__init__.py", line 338,
 in execute_from_command_line
 utility.execute()
 File "...\site-packages\django\core\management\__init__.py", line 330,
 in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
 File "...\site-packages\django\core\management\base.py", line 390, in
 run_from_argv
 self.execute(*args, *\*cmd_options)
 File "...\site-packages\django\core\management\base.py", line 441, in
 execute
 output = self.handle(*args, *\*options)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 179, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 317, in sync_apps
 cursor.execute(statement)
 File "...\site-packages\django\db\backends\utils.py", line 79, in
 execute
 return super(CursorDebugWrapper, self).execute(sql, params)
 File "...\site-packages\django\db\backends\utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
 File "...\site-packages\django\db\utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
 File "...\site-packages\django\db\backends\utils.py", line 62, in
 execute
 return self.cursor.execute(sql)
 django.db.utils.ProgrammingError: relation "auth_group" does not exist

 What happens is that the django_migrations table gets created. Creation of
 all other tables are discarded/reverted due to this error.

 If necessary, I may be able to provide a minimal code for reproducing this
 issue. It's happening in five independent projects for me. I hope I'm
 doing something wrong here, but it may just as well be a bug.

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

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by SimonSteinberger):

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


Old description:

> Using an AbstractUser based user model with Django 1.8 RC1 causes the
> management command to create the database table layout to fail: "python
> manage.py migrate"
>
> Traceback:
> File "manage.py", line 9, in 
> execute_from_command_line(sys.argv)
> File "...\site-packages\django\core\management\__init__.py", line
> 338, in execute_from_command_line
> utility.execute()
> File "...\site-packages\django\core\management\__init__.py", line
> 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File "...\site-packages\django\core\management\base.py", line 390, in
> run_from_argv
> self.execute(*args, *\*cmd_options)
> File "...\site-packages\django\core\management\base.py", line 441, in
> execute
> output = self.handle(*args, *\*options)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 317, in sync_apps
> cursor.execute(statement)
> File "...\site-packages\django\db\backends\utils.py", line 79, in
> execute
> return super(CursorDebugWrapper, self).execute(sql, params)
> File "...\site-packages\django\db\backends\utils.py", line 64, in
> execute
> return self.cursor.execute(sql, params)
> File "...\site-packages\django\db\utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
> File "...\site-packages\django\db\backends\utils.py", line 62, in
> execute
> return self.cursor.execute(sql)
> django.db.utils.ProgrammingError: relation "auth_group" does not
> exist
>
> What happens is that the django_migrations table gets created. Creation
> of all other tables are discarded/reverted due to this error.
>
> If necessary, I may be able to provide a minimal code for reproducing
> this issue. It's happening in five independent projects for me. I hope
> I'm doing something wrong here, but it may just as well be a bug.

New description:

 Using an AbstractUser based user model with Django 1.8 RC1 causes the
 management command to create the table layout on a *new and empty
 database* to fail: "python manage.py migrate"

 Traceback:
 File "manage.py", line 9, in 
 execute_from_command_line(sys.argv)
 File "...\site-packages\django\core\management\__init__.py", line 338,
 in execute_from_command_line
 utility.execute()
 File "...\site-packages\django\core\management\__init__.py", line 330,
 in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
 File "...\site-packages\django\core\management\base.py", line 390, in
 run_from_argv
 self.execute(*args, *\*cmd_options)
 File "...\site-packages\django\core\management\base.py", line 441, in
 execute
 output = self.handle(*args, *\*options)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 179, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 317, in sync_apps
 cursor.execute(statement)
 File "...\site-packages\django\db\backends\utils.py", line 79, in
 execute
 return super(CursorDebugWrapper, self).execute(sql, params)
 File "...\site-packages\django\db\backends\utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
 File "...\site-packages\django\db\utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
 File "...\site-packages\django\db\backends\utils.py", line 62, in
 execute
 return self.cursor.execute(sql)
 django.db.utils.ProgrammingError: relation "auth_group" does not exist

 What happens is that the django_migrations table gets created. Creation of
 all other tables are discarded/reverted due to this error.

 If necessary, I may be able to provide a minimal code for reproducing this
 issue. It's happ

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by SimonSteinberger:

Old description:

> Using an AbstractUser based user model with Django 1.8 RC1 causes the
> management command to create the table layout on a *new and empty
> database* to fail: "python manage.py migrate"
>
> Traceback:
> File "manage.py", line 9, in 
> execute_from_command_line(sys.argv)
> File "...\site-packages\django\core\management\__init__.py", line
> 338, in execute_from_command_line
> utility.execute()
> File "...\site-packages\django\core\management\__init__.py", line
> 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File "...\site-packages\django\core\management\base.py", line 390, in
> run_from_argv
> self.execute(*args, *\*cmd_options)
> File "...\site-packages\django\core\management\base.py", line 441, in
> execute
> output = self.handle(*args, *\*options)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 317, in sync_apps
> cursor.execute(statement)
> File "...\site-packages\django\db\backends\utils.py", line 79, in
> execute
> return super(CursorDebugWrapper, self).execute(sql, params)
> File "...\site-packages\django\db\backends\utils.py", line 64, in
> execute
> return self.cursor.execute(sql, params)
> File "...\site-packages\django\db\utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
> File "...\site-packages\django\db\backends\utils.py", line 62, in
> execute
> return self.cursor.execute(sql)
> django.db.utils.ProgrammingError: relation "auth_group" does not
> exist
>
> What happens is that the django_migrations table gets created. Creation
> of all other tables are discarded/reverted due to this error.
>
> If necessary, I may be able to provide a minimal code for reproducing
> this issue. It's happening in five independent projects for me. I hope
> I'm doing something wrong here, but it may just as well be a bug.

New description:

 Using an AbstractUser based user model with Django 1.8 RC1 causes the
 management command to create the table layout on a *new and empty
 database* to fail: "python manage.py migrate"

 Traceback:
 File "manage.py", line 9, in 
 execute_from_command_line(sys.argv)
 File "...\site-packages\django\core\management\__init__.py", line 338,
 in execute_from_command_line
 utility.execute()
 File "...\site-packages\django\core\management\__init__.py", line 330,
 in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
 File "...\site-packages\django\core\management\base.py", line 390, in
 run_from_argv
 self.execute(*args, *\*cmd_options)
 File "...\site-packages\django\core\management\base.py", line 441, in
 execute
 output = self.handle(*args, *\*options)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 179, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
 File "...\site-packages\django\core\management\commands\migrate.py",
 line 317, in sync_apps
 cursor.execute(statement)
 File "...\site-packages\django\db\backends\utils.py", line 79, in
 execute
 return super(CursorDebugWrapper, self).execute(sql, params)
 File "...\site-packages\django\db\backends\utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
 File "...\site-packages\django\db\utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
 File "...\site-packages\django\db\backends\utils.py", line 62, in
 execute
 return self.cursor.execute(sql)
 django.db.utils.ProgrammingError: relation "auth_group" does not exist

 What happens is that the django_migrations table gets created. Creation of
 all other tables are discarded/reverted due to this error.

 If necessary, I may be able to provide a minimal code for reproducing this
 issue. It's happening in five independent projects for me. I h

Re: [Django] #12400: column "X" named in key does not exist error when models.PointField used in unique_together

2015-03-23 Thread Django

#12400: column "X" named in key does not exist error when models.PointField 
used in
unique_together
+-
 Reporter:  monkut  |Owner:  claudep
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24497: Truncation of microseconds in DateTimeField leads to lookup trouble

2015-03-23 Thread Django

#24497: Truncation of microseconds in DateTimeField leads to lookup trouble
--+
 Reporter:  riklaunim |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  microseconds  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by wdmgsm):

 It was suggested by bmispelon in this
 [https://github.com/django/django/pull/4373 pull request] to add
 {{{supports_microseconds}}} to the base {{{Widget}}} class so that all
 derived widgets inherit it.

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

Re: [Django] #13525: Document how to reverse URL patterns with nested groups

2015-03-23 Thread Django

#13525: Document how to reverse URL patterns with nested groups
-+-
 Reporter:  nickretallack|Owner:  bpeschier
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"23a5d64f40b0f4a3fbfef7427ca793cb1df1034e" 23a5d64f]:
 {{{
 #!CommitTicketReference repository=""
 revision="23a5d64f40b0f4a3fbfef7427ca793cb1df1034e"
 Fixed #13525 -- Added tests and docs for nested parameters in URL
 patterns.

 When reversing, only outer parameters are used if captured parameters are
 nested. Added tests to check the edge cases and documentation for the
 behavior with an example to avoid it.
 }}}

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

Re: [Django] #13525: Document how to reverse URL patterns with nested groups

2015-03-23 Thread Django

#13525: Document how to reverse URL patterns with nested groups
-+-
 Reporter:  nickretallack|Owner:  bpeschier
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"015a9b928af233ca036b93a4d7eecf18f15cbc2b" 015a9b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="015a9b928af233ca036b93a4d7eecf18f15cbc2b"
 [1.8.x] Fixed #13525 -- Added tests and docs for nested parameters in URL
 patterns.

 When reversing, only outer parameters are used if captured parameters are
 nested. Added tests to check the edge cases and documentation for the
 behavior with an example to avoid it.

 Backport of 23a5d64f40b0f4a3fbfef7427ca793cb1df1034e 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/071.b66cec972d4fa47470c12144bc3e7030%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Yes, we will need some more details.

 Do your apps have migrations? Are you mixing apps with migrations and apps
 without migrations?

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

Re: [Django] #24244: Document contrib.admin.models.LogEntry

2015-03-23 Thread Django

#24244: Document contrib.admin.models.LogEntry
--+
 Reporter:  timgraham |Owner:  varun
 Type:  New feature   |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"74f8110e74927c231bfcd106fa28bf6e6dd034e6" 74f8110e]:
 {{{
 #!CommitTicketReference repository=""
 revision="74f8110e74927c231bfcd106fa28bf6e6dd034e6"
 Added test for LogEntry.get_edited_object(); refs #24244.
 }}}

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

Re: [Django] #24244: Document contrib.admin.models.LogEntry

2015-03-23 Thread Django

#24244: Document contrib.admin.models.LogEntry
--+
 Reporter:  timgraham |Owner:  varun
 Type:  New feature   |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"8f5e8ab666bcc6e2dae9f147ac804f098fcb3f78" 8f5e8ab6]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f5e8ab666bcc6e2dae9f147ac804f098fcb3f78"
 [1.8.x] Added test for LogEntry.get_edited_object(); refs #24244.

 Backport of 74f8110e74927c231bfcd106fa28bf6e6dd034e6 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/067.34df9a6bb8c28e8d3c0ce8c6c3f51205%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24244: Document contrib.admin.models.LogEntry

2015-03-23 Thread Django

#24244: Document contrib.admin.models.LogEntry
--+
 Reporter:  timgraham |Owner:  varun
 Type:  New feature   |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  afraid-to-commit  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  1 => 0


Comment:

 I committed the test, we can keep this ticket open for the documentation.

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

Re: [Django] #16362: Ignore, rather than disallow, negative lookahead assertions

2015-03-23 Thread Django

#16362: Ignore, rather than disallow, negative lookahead assertions
-+-
 Reporter:  charles@…|Owner:  bpeschier
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b4382b7055fc8b0078cbb50ed9c3f924635d9971" b4382b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4382b7055fc8b0078cbb50ed9c3f924635d9971"
 Fixed #16362 -- Allowed lookaround assertions in URL patterns.
 }}}

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by MarkusH:

Old description:

> Using an AbstractUser based user model with Django 1.8 RC1 causes the
> management command to create the table layout on a *new and empty
> database* to fail: "python manage.py migrate"
>
> Traceback:
> File "manage.py", line 9, in 
> execute_from_command_line(sys.argv)
> File "...\site-packages\django\core\management\__init__.py", line
> 338, in execute_from_command_line
> utility.execute()
> File "...\site-packages\django\core\management\__init__.py", line
> 330, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File "...\site-packages\django\core\management\base.py", line 390, in
> run_from_argv
> self.execute(*args, *\*cmd_options)
> File "...\site-packages\django\core\management\base.py", line 441, in
> execute
> output = self.handle(*args, *\*options)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 179, in handle
> created_models = self.sync_apps(connection,
> executor.loader.unmigrated_apps)
> File "...\site-packages\django\core\management\commands\migrate.py",
> line 317, in sync_apps
> cursor.execute(statement)
> File "...\site-packages\django\db\backends\utils.py", line 79, in
> execute
> return super(CursorDebugWrapper, self).execute(sql, params)
> File "...\site-packages\django\db\backends\utils.py", line 64, in
> execute
> return self.cursor.execute(sql, params)
> File "...\site-packages\django\db\utils.py", line 97, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
> File "...\site-packages\django\db\backends\utils.py", line 62, in
> execute
> return self.cursor.execute(sql)
> django.db.utils.ProgrammingError: relation "auth_group" does not
> exist
>
> What happens is that the django_migrations table gets created. Creation
> of all other tables are discarded/reverted due to this error.
>
> If necessary, I may be able to provide a minimal code for reproducing
> this issue. It's happening in five independent projects for me. I hope
> I'm doing something wrong here, but it may just as well be a bug.
>
> Possible solution is not to do any automatic migrations when creating a
> fresh database table layout.

New description:

 Using an `AbstractUser` based user model with Django 1.8 RC1 causes the
 management command to create the table layout on a *new and empty
 database* to fail: `python manage.py migrate`

 {{{#!python
 Traceback:
   File "manage.py", line 9, in 
 execute_from_command_line(sys.argv)
   File "...\site-packages\django\core\management\__init__.py", line 338,
 in execute_from_command_line
 utility.execute()
   File "...\site-packages\django\core\management\__init__.py", line 330,
 in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "...\site-packages\django\core\management\base.py", line 390, in
 run_from_argv
 self.execute(*args, *\*cmd_options)
   File "...\site-packages\django\core\management\base.py", line 441, in
 execute
 output = self.handle(*args, *\*options)
   File "...\site-packages\django\core\management\commands\migrate.py",
 line 179, in handle
 created_models = self.sync_apps(connection,
 executor.loader.unmigrated_apps)
   File "...\site-packages\django\core\management\commands\migrate.py",
 line 317, in sync_apps
 cursor.execute(statement)
   File "...\site-packages\django\db\backends\utils.py", line 79, in
 execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "...\site-packages\django\db\backends\utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
   File "...\site-packages\django\db\utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "...\site-packages\django\db\backends\utils.py", line 62, in
 execute
 return self.cursor.execute(sql)
 django.db.utils.ProgrammingError: relation "auth_group" does not exist
 }}}

 What happens is that the `django_migrations` table gets created. Creation
 of all other tables are discarded/reverted due to this error.

 If necessary, I may be able to provide a min

Re: [Django] #15667: Implement template-based widget rendering

2015-03-23 Thread Django

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  auvipy
 Type:  New feature |   Status:  assigned
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by auvipy):

 * status:  new => assigned
 * owner:  brutasse => auvipy


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

Re: [Django] #15667: Implement template-based widget rendering

2015-03-23 Thread Django

Comment (by auvipy):

Replying to [comment:43 timgraham]:
> I haven't read through all the history of this ticket, but I guess it
might work something like this: by default, widgets are rendered with
Django templates. If you have jinja2 configured in `TEMPLATES`, then
widgets can be rendered with it. The main point is not to add jinja2 as a
requirement for Django.

That is what I'm thinking, as aymeric says masters has first class support
for jinja2 does that mean using jinja2 for form rendering and then modify
the contrib apps widgets with that? for standardizing django form
rendering what should be the move? stick with django or switching to
jinja2 permanently? or keeping to versions of different form rendering
system? 1 for backward compat and another for futureistic?

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
Reporter: SimonSteinberger |Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.8rc1
Severity: Release blocker | Resolution: invalid
Keywords: migrations, fail,| Triage Stage:
collision | Unreviewed
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-
Changes (by MarkusH):

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

Comment:

I digged into the issue. It occurs on Postgres when the app with the
custom user model does not have migrations due to the dependency of your
user model on `auth.Group`. In accordance with the documentation this is
an unsupported behavior:

Be aware, however, that unmigrated apps cannot depend on migrated
apps, by the very nature of not having migrations. This means that it is
not generally possible to have an unmigrated app have a `ForeignKey` or
`ManyToManyField` to a migrated app; some cases may work, but it will
eventually fail.
https://docs.djangoproject.com/en/1.8/topics/migrations/#dependencies

I thus close this ticket as expected behavior.

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

Re: [Django] #24505: Multiple ManyToManyFields to same "to" model with related_name set to '+' mix up badly

2015-03-23 Thread Django

#24505: Multiple ManyToManyFields to same "to" model with related_name set to 
'+'
mix up badly
-+-
 Reporter:  gergelypolonkai  |Owner:
 |  marcofucci
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by marcofucci):

 I did a bit of research after `jtiai` pointed me in the right direction
 and it seems that we've had the same problem before.

 To fix the problem, we documented a workaround where `related_name`s had
 to be unique, even the ones ending in `+` #15932.

 We then thought we had fixed it in #21375 so we deleted the documented
 workaround #21491.

 Finally, it seems that the bug is back and addressed 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/073.0e37ad48953ea594f2fcc7ec9d3e7312%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11390: If you use a callable as default value on a model field, it gets called 3 times.

2015-03-23 Thread Django

#11390: If you use a callable as default value on a model field, it gets called 
3
times.
--+
 Reporter:  espen.nettbruk@…  |Owner:  tomviner
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.0
 Severity:  Normal|   Resolution:
 Keywords:  models| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"a4a58811b9729ed1ab2417d72e5d07ebb1a30886" a4a58811]:
 {{{
 #!CommitTicketReference repository=""
 revision="a4a58811b9729ed1ab2417d72e5d07ebb1a30886"
 Removed redundant model instantiation in contrib.admin; refs #11390.
 }}}

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

Re: [Django] #11390: If you use a callable as default value on a model field, it gets called 3 times.

2015-03-23 Thread Django

#11390: If you use a callable as default value on a model field, it gets called 
3
times.
--+
 Reporter:  espen.nettbruk@…  |Owner:  tomviner
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.0
 Severity:  Normal|   Resolution:
 Keywords:  models| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * has_patch:  1 => 0


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

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

Re: [Django] #24361: The doc is not right w.r.t. LOGGING overwriting.

2015-03-23 Thread Django

#24361: The doc is not right w.r.t. LOGGING overwriting.
---+
 Reporter:  Tuttle |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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 timgraham):

 * stage:  Ready for checkin => 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.570d15615546f92cfb6d89bed9a9e0af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24134: Document short command line options for management commands

2015-03-23 Thread Django

#24134: Document short command line options for management commands
--+
 Reporter:  mjtamlyn  |Owner:  staeff
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 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 timgraham):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * stage:  Ready for checkin => Accepted


Comment:

 The docs build doesn't pass with this change.

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

Re: [Django] #24513: "... has no field named None" with M2MField when migrating

2015-03-23 Thread Django

#24513: "... has no field named None" with M2MField when migrating
-+--
 Reporter:  Kondou-ger   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, bug  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by MarkusH):

 I think the unique_together constraint is part of the m2m through table
 which is automatically created by Django (which is ``). The odd thing, the field `None` should be
 `user` (FK from the m2m through table to your user model table). I have no
 idea yet why or where the name resolution fails / the field cache isn't
 cleared.

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

Re: [Django] #23697: Confusing exception raised upon unknown field in queryset filter argument

2015-03-23 Thread Django

#23697: Confusing exception raised upon unknown field in queryset filter 
argument
-+-
 Reporter:  mbertheau|Owner:  exonian
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"00e667728ba3ef1b5cb3de0e11c7648b89315a91" 00e66772]:
 {{{
 #!CommitTicketReference repository=""
 revision="00e667728ba3ef1b5cb3de0e11c7648b89315a91"
 Fixed #23697 -- Improved ForeignObject.get_lookup_constraint() error
 message.
 }}}

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

Re: [Django] #24520: Add documentation for supports_microseconds widget property

2015-03-23 Thread Django

#24520: Add documentation for supports_microseconds widget property
--+
 Reporter:  pkatseas  |Owner:  wdmgsm
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 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 timgraham):

 * has_patch:  0 => 1
 * 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/066.3fda3cc240e4033793f941a14ec33c44%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:  invalid
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by SimonSteinberger):

 You're right - those are PostgreSQL driven app. Can you point me into the
 right direction how to avoid this issue, when using a very simple
 AbstractUser model without any additional fields?

 I think that's a pretty normal use case. A solution should be pointed out
 in the documentation. And despite I'm pretty experienced with Django in
 general (and very happy with it), I can't see how to avoid this problem
 ...

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

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

Re: [Django] #24521: frozensets don't seem to work quite right in migrations as field kwargs

2015-03-23 Thread Django

#24521: frozensets don't seem to work quite right in migrations as field kwargs
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migration kwarg  | Triage Stage:  Accepted
  frozenset  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 PR here: https://github.com/django/django/pull/4387

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

Re: [Django] #24470: Serialization of base classes is not customizable for migrations

2015-03-23 Thread Django

#24470: Serialization of base classes is not customizable for migrations
-+
 Reporter:  rockymeza|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 MarkusH):

 It would be nice if we can stick to `deconstruct()` and not introduce
 `deconstruct_class()`.

 For serializing model managers we follow the pattern `class
 MyManager(MyBaseManager.from_queryset(CustomQuerySet)):`
 https://docs.djangoproject.com/en/1.8/topics/migrations/#model-managers
 which will also work here I think.

 I have to think about it a bit more, though, but the general feature seems
 useful for more complex projects.

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

Re: [Django] #24442: Index name truncation is odd

2015-03-23 Thread Django

#24442: Index name truncation is odd
+
 Reporter:  shaib   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  oracle  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by MarkusH):

 * cc: MarkusH (added)


Comment:

 This is related to f37c11eea3cb860112a26f8a65d823842f65b96f and #24390.

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

Re: [Django] #24521: frozensets don't seem to work quite right in migrations as field kwargs

2015-03-23 Thread Django

#24521: frozensets don't seem to work quite right in migrations as field kwargs
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migration kwarg  | Triage Stage:  Ready for
  frozenset  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24521: frozensets don't seem to work quite right in migrations as field kwargs

2015-03-23 Thread Django

#24521: frozensets don't seem to work quite right in migrations as field kwargs
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration kwarg  | Triage Stage:  Ready for
  frozenset  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon ):

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


Comment:

 In [changeset:"1aadade373336c3f534986cdcc0ba33714d85c8e" 1aadade]:
 {{{
 #!CommitTicketReference repository=""
 revision="1aadade373336c3f534986cdcc0ba33714d85c8e"
 Fixed #24521 -- Added support for serializing frozensets in migrations.
 }}}

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

Re: [Django] #24440: Debug.py could use additional padding for individual stack rows.

2015-03-23 Thread Django

#24440: Debug.py could use additional padding for individual stack rows.
-+-
 Reporter:  commadelimited   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  debug padding| Triage Stage:  Accepted
  spacing|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b4da88b1268668c11dd999a7a0915193c204bf04" b4da88b]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4da88b1268668c11dd999a7a0915193c204bf04"
 Fixed #24440 -- Added padding to debug view stacktrace lines.
 }}}

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

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

2015-03-23 Thread Django

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
---+--
 Reporter:  kalium99   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.7
 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 timgraham):

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


Comment:

 I'm not sure it would resolve the issue, but I'm concerned that your
 `PartnerSelection` form is running database queries at import time. Can
 you confirm that or paste the entire form so we can see about that?

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

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

Re: [Django] #10060: Multiple table annotation failure

2015-03-23 Thread Django

Comment (by camillobruni):

I recently ran into a similar problem. The deep joining causes an
explosion of values possibly resulting in many duplicate values. I fixed
this in https://github.com/django/django/pull/4388 by implementing the
DISTINCT parameter on the Aggregate functions. Hence you can do
{{{Sum('center__client__loan__payment_schedule__payments__principal',
distinct=True)}}}
which ignores the duplicate entries.

It might be that the issue at hand is slightly different, but this solves
at least one particular case.

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

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

Re: [Django] #24347: parameter 'widget' of BoundField.as_widget is ignored

2015-03-23 Thread Django

#24347: parameter 'widget' of BoundField.as_widget is ignored
-+-
 Reporter:  srkunze  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8beta1
 Severity:  Normal   |   Resolution:
 Keywords:  BoundField,  | Triage Stage:  Accepted
  as_widget, hidden, initial,|
  hidden_initial |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by srkunze):

 * keywords:  BoundField, as_widget => BoundField, as_widget, hidden,
 initial, hidden_initial
 * needs_docs:  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/065.22dcfae033603fdfb187d6fa768b063c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11390: If you use a callable as default value on a model field, it gets called 3 times.

2015-03-23 Thread Django

#11390: If you use a callable as default value on a model field, it gets called 
3
times.
--+
 Reporter:  espen.nettbruk@…  |Owner:
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.0
 Severity:  Normal|   Resolution:
 Keywords:  models| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by tomviner):

 * owner:  tomviner =>
 * status:  assigned => new


Comment:

 Thanks for the merge.

 One down one to go. But as I mentioned earlier, I'm not sure how or if
 it's possible to combine the two remaining calls.

 This simple example shows the 2 calls:

 {{{
 In [1]: from django.forms.models import modelform_factory

 In [2]: from cad.models import Article

 In [3]: article_modelform = modelform_factory(Article, fields=('title',))

 In [4]: form = article_modelform()
 get_default_title call #1

 In [5]: form.as_p()
 get_default_title call #2
 Out[5]: u'...
 }}}

 One's the in memory model being instantiated and the other's the ModelForm
 field/widget populating it's values. They seem separate and I'm not sure
 where any memoisation of this value would go or if it would be a great
 idea.

 I'll unassign myself so others can either take a stab, or chime in that
 it's not a worthy goal.

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

Re: [Django] #24483: keepdb migrations break choices as generators

2015-03-23 Thread Django

#24483: keepdb migrations break choices as generators
-+-
 Reporter:  davidszotten |Owner:
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations test  | Triage Stage:  Accepted
  keepdb |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #12400: column "X" named in key does not exist error when models.PointField used in unique_together

2015-03-23 Thread Django

#12400: column "X" named in key does not exist error when models.PointField 
used in
unique_together
+-
 Reporter:  monkut  |Owner:  claudep
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Ready for checkin
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"01ec127baec38b7f8281e6eca9def40f22c9e5ad" 01ec127b]:
 {{{
 #!CommitTicketReference repository=""
 revision="01ec127baec38b7f8281e6eca9def40f22c9e5ad"
 Fixed #12400 -- Allowed geometry fields in unique_together

 Thanks Tim Graham for the review.
 }}}

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

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

[Django] #24525: AssertionError at `Query.change_aliases`

2015-03-23 Thread Django

#24525: AssertionError at `Query.change_aliases`
--+
 Reporter:  coolRR|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 (Django version 1.7.7)

 I'm getting an assertion error on the first line of
 `Query.change_aliases`:

 assert
 set(change_map.keys()).intersection(set(change_map.values())) == set()

 Problem is, I can't post more data, because the queryset has confidential
 client information :(

 I can post the value of `change_map`, with identifying details renamed:

 {'T5': 'T10',
  'T6': 'T11',
  'T8': 'T13',
  'my_app_follow': 'my_app_follow',
  'my_app_stack__readers': 'T7',
  'my_app_stack__writers': 'T9',
  'my_app_user': 'T8'}

 This happened when doing `&` on two querysets, one of which having
 `.distinct()` applied on it, among other things.

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2015-03-23 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by coolRR):

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


Old description:

> (Django version 1.7.7)
>
> I'm getting an assertion error on the first line of
> `Query.change_aliases`:
>
> assert
> set(change_map.keys()).intersection(set(change_map.values())) == set()
>
> Problem is, I can't post more data, because the queryset has confidential
> client information :(
>
> I can post the value of `change_map`, with identifying details renamed:
>
> {'T5': 'T10',
>  'T6': 'T11',
>  'T8': 'T13',
>  'my_app_follow': 'my_app_follow',
>  'my_app_stack__readers': 'T7',
>  'my_app_stack__writers': 'T9',
>  'my_app_user': 'T8'}
>
> This happened when doing `&` on two querysets, one of which having
> `.distinct()` applied on it, among other things.

New description:

 (Django version 1.7.7)

 I'm getting an assertion error on the first line of
 `Query.change_aliases`:

 {{{
 assert
 set(change_map.keys()).intersection(set(change_map.values())) == set()
 }}}

 Problem is, I can't post more data, because the queryset has confidential
 client information :(

 I can post the value of `change_map`, with identifying details renamed:

 {{{
 {'T5': 'T10',
  'T6': 'T11',
  'T8': 'T13',
  'my_app_follow': 'my_app_follow',
  'my_app_stack__readers': 'T7',
  'my_app_stack__writers': 'T9',
  'my_app_user': 'T8'}
 }}}

 This happened when doing `&` on two querysets, one of which having
 `.distinct()` applied on it, among other things.

--

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by subsume):

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


Comment:

 I'd love to provide any information needed. I am experiencing the same
 bug. To be clear, this started happening on a very large scale once I
 upgraded from 1.4.3 to 1.6.X.

 It also mirrors a situation that's happening here:
 http://stackoverflow.com/questions/10264437/django-forbidden-csrf-cookie-
 not-set

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timgraham):

 The way to help is by giving us steps so we can reproduce the error and
 debug it.

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2015-03-23 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Couldn't you change the names of the models and values of the data and
 offer a test case to reproduce the error?

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

Re: [Django] #12400: column "X" named in key does not exist error when models.PointField used in unique_together

2015-03-23 Thread Django

#12400: column "X" named in key does not exist error when models.PointField 
used in
unique_together
+
 Reporter:  monkut  |Owner:  claudep
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by timgraham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 Crash on Oracle after this change:
 {{{
 Traceback (most recent call last):
   File "./runtests.py", line 434, in 
 options.debug_sql)
   File "./runtests.py", line 256, in django_tests
 extra_tests=extra_tests,
   File "/home/jenkins/workspace/django-
 oracle/database/oragis11/label/trusty/python/python2.7/django/test/runner.py",
 line 210, in run_tests
 old_config = self.setup_databases()
   File "/home/jenkins/workspace/django-
 oracle/database/oragis11/label/trusty/python/python2.7/django/test/runner.py",
 line 166, in setup_databases
 **kwargs
   File "/home/jenkins/workspace/django-
 oracle/database/oragis11/label/trusty/python/python2.7/django/test/runner.py",
 line 370, in setup_databases
 serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE",
 True),
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/db/backends/base/creation.py",
 line 71, in create_test_db
 run_syncdb=True,
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/core/management/__init__.py",
 line 118, in call_command
 return command.execute(*args, **defaults)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/core/management/base.py",
 line 398, in execute
 output = self.handle(*args, **options)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/core/management/commands/migrate.py",
 line 168, in handle
 self.sync_apps(connection, executor.loader.unmigrated_apps)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/core/management/commands/migrate.py",
 line 288, in sync_apps
 cursor.execute(statement)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/db/backends/utils.py",
 line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/jenkins/workspace/django-
 oracle/database/oragis11/label/trusty/python/python2.7/django/db/utils.py",
 line 95, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/db/backends/utils.py",
 line 62, in execute
 return self.cursor.execute(sql)
   File "/home/jenkins/workspace/django-
 
oracle/database/oragis11/label/trusty/python/python2.7/django/db/backends/oracle/base.py",
 line 478, in execute
 return self.cursor.execute(query, self._param_generator(params))
 django.db.utils.DatabaseError: ORA-02329: column of datatype ADT cannot be
 unique or a primary key
 }}}

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2015-03-23 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by coolRR):

 These querysets are passed through several functions in different files so
 it'll be hard to construct them in straight code. It'll be about an hour
 of work for me which is too much.

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by subsume):

 I'd love to be able to reproduce it, still just debugging over email with
 users (lots of them).

 The docs do say "Regardless, you’re guaranteed to have the cookie if the
 token is present in the DOM, so you should use the cookie!" is this true?
 If so, the error message "not set" seems errant.

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2015-03-23 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Well, trying to reproduce this from the provided details will likely take
 much longer than an hour.

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

[Django] #24526: Default logging config filters out anything below ERROR for django.request/django.security loggers

2015-03-23 Thread Django

#24526: Default logging config filters out anything below ERROR for
django.request/django.security loggers
-+-
   Reporter:  timgraham  |  Owner:  timgraham
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (Other)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The fact that the `django.request` and `django.security` handlers define:
 {{{
 'level': 'ERROR',
 'propagate': False,
 }}}
 makes it impossible to configure other handlers to catch these errors.

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

Comment (by subsume):

I was able to verify that the csrftoken in the form and the csrf cookie
are both present and match before failure.

I had the user delete the csrf cookie and retry and it issued a new one
which failed.

I was also able to take over a user's session normally by taking their
cookie value and replacing my own locally with it. While their environment
still failed, mine was able to use the site normally. (while they can
maintain their session while the problem is happening, they can't submit
csrf forms).

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by prestontimmons):

 Which version of Django and Python are you seeing this on?

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by subsume):

 py 2.7.8  / dj 1.6.10

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

Re: [Django] #23658: Provide the password to PostgreSQL from "dbshell" command

2015-03-23 Thread Django

#23658: Provide the password to PostgreSQL from "dbshell" command
-+-
 Reporter:  etanol   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql dbshell   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by rhertzog):

 I would like to point out the discussion we just had on
 http://bugs.debian.org/781033 : namely that PGPASSWD is a deprecated
 feature. The correct way to handle this would be to setup a temporary
 password file that is then passed to the PGPASSFILE environment variable.

 http://www.postgresql.org/docs/9.0/interactive/libpq-envars.html
 https://stackoverflow.com/questions/6523019/postgresql-scripting-psql-
 execution-with-password

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by SimonSteinberger):

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


Comment:

 Well, I've digged into this myself now, and I must say: This is completely
 nonsensical:

 When using the AbstractUser class to create a custom user model *exactly
 as outlined in Django's docs* at least the first "manage.py migrate" must
 work and must create an empty database table layout. The sole purpose of
 the AbstractUser class is to extend the basic user with more fields. But
 as you describe it, the whole class is just useless and doomed to fail. By
 teh way: Permissions and auth group tables are automatically created with
 the AbstractUser model.

 So, either I'm doing something plainly wrong here, or the docs are lacking
 some critical information/solutions, or the whole construct doesn't male
 sense as it is.

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Release blocker  |   Resolution:
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 Did you run `python manage.py makemigrations appname` first, where
 "appname" is the name of the app containing your custom user model
 inheriting from `AbstractUser`?

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by prestontimmons):

 This may be a bug in Python 2.7.8. Django uses the standard library
 `Cookie` implementation, which introduced some problems in recent
 releases. For example, https://bugs.python.org/issue22931.

 Can you tell if another cookie is causing `Cookie.load()` to drop the
 csrftoken value during parsing?

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

Re: [Django] #24524: Automatic migrations prevent creation of initial database table layout

2015-03-23 Thread Django

#24524: Automatic migrations prevent creation of initial database table layout
-+-
 Reporter:  SimonSteinberger |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  1.8rc1
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations, fail,| Triage Stage:
  collision  |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by SimonSteinberger):

 * status:  new => closed
 * needs_docs:  0 => 1
 * type:  Bug => Cleanup/optimization
 * resolution:   => worksforme
 * severity:  Release blocker => Normal


Comment:

 Okay, that worked. Thanks a lot!

 I assume it's somewhere in the docs - or maybe not. At least I couldn't
 find it - and I think it is an extremely important point that should
 appear in a warning box at the AbstractUser documentation.

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

[Django] #24527: Using standalone templates gives confusing error message

2015-03-23 Thread Django

#24527: Using standalone templates gives confusing error message
---+---
 Reporter:  cjerdonek  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:  templates, standalone
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 I'm trying to use Django templates in "standalone" fashion, and I'm
 getting the following `AppRegistryNotReady` error at bottom (with version
 1.7.7).

 The error is confusing because my understanding from
 [https://docs.djangoproject.com/en/dev/topics/settings/#using-settings-
 without-setting-django-settings-module the documentation] is that calling
 the following is sufficient before using Django's template code:

 {{{
 django.conf.settings.configure()
 }}}

 Here is the stack trace:

 {{{
 File
 "/Users/chris/dev/.virtualenvs/my_package/scripts/../pyelect/htmlgen.py",
 line 171, in render_template
 template = get_template(template_name, dirs=[])
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/template/loader.py", line 144, in get_template
 template, origin = find_template(template_name, dirs)
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/template/loader.py", line 126, in find_template
 loader = find_template_loader(loader_name)
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/template/loader.py", line 98, in find_template_loader
 TemplateLoader = import_string(loader)
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/utils/module_loading.py", line 26, in import_string
 module = import_module(module_path)
   File
 "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/importlib/__init__.py",
 line 109, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 2254, in _gcd_import
   File "", line 2237, in _find_and_load
   File "", line 2226, in
 _find_and_load_unlocked
   File "", line 1200, in _load_unlocked
   File "", line 1129, in _exec
   File "", line 1471, in exec_module
   File "", line 321, in
 _call_with_frames_removed
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/template/loaders/app_directories.py", line 33, in 
 app_template_dirs = calculate_app_template_dirs()
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/template/loaders/app_directories.py", line 21, in
 calculate_app_template_dirs
 for app_config in apps.get_app_configs():
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/apps/registry.py", line 137, in get_app_configs
 self.check_apps_ready()
   File "/Users/chris/dev/.virtualenvs/my_package/lib/python3.4/site-
 packages/django/apps/registry.py", line 124, in check_apps_ready
 raise AppRegistryNotReady("Apps aren't loaded yet.")
 django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.


 }}}

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

Re: [Django] #24280: CSRF cookie error only happening with Chrome.

2015-03-23 Thread Django

#24280: CSRF cookie error only happening with Chrome.
-+--
 Reporter:  jkapple  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  1.6
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSRF, chrome | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by subsume):

 That's a bingo. As soon as I modified a local cookie to include a ], i
 instantly lost my django session (which makes no sense). The next login
 attempt was a bust. Removing the bracket restores my session :P Great
 find.

 As for why Chrome users seem to report things far more than users of other
 browsers I leave up to the theologians. It was an uncanny red herring 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/065.e4c9f28ac24f15fe5ce8f8b4f2da4aeb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24527: Using standalone templates gives confusing error message

2015-03-23 Thread Django

#24527: Using standalone templates gives confusing error message
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  templates,   | Triage Stage:
  standalone |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cjerdonek):

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


Comment:

 Investigating further, it looks like this is because
 `django.template.loaders.app_directories.Loader` is part of the default
 `TEMPLATE_LOADERS` setting.  But the
 [https://docs.djangoproject.com/en/1.7/ref/templates/api/#configuring-the-
 template-system-in-standalone-mode documentation for using templates in
 standalone] doesn't say this setting needs to be manually set.

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

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

2015-03-23 Thread Django

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
---+--
 Reporter:  kalium99   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by kalium99):

 That's right, the `PartnerSelection` form is running database queries.
 This situation is not ideal for a couple of reasons (not in the least that
 the field is not updated until a process is recycled).
 {{{
   class PartnerSelection(forms.Form):
   partner = forms.ChoiceField(label='Partner', choices=[ (p.id,
 p.company_name)
   for p in Partner.objects.all()])
 }}}
 So moving this (and anything similar) would solve this particular instance
 of the problem, but not the underlying issue in 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/066.861143eb957222a1c1b7145cc9b65dec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' error when loading data

2015-03-23 Thread Django

#24512: 'ORA-01461: can bind a LONG value only for insert into a LONG column' 
error
when loading data
-+-
 Reporter:  hadalin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | 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 hadalin:

Old description:

> ''ORA-01461: can bind a LONG value only for insert into a LONG column''
> is raised when loading data into TextField (NCLOB) with ''python
> manage.py loaddata''
>
> Test Django project and steps to reproduce are here
> [https://github.com/hadalin/django-oracle-test]

New description:

 When using Oracle backend ''ORA-01461: can bind a LONG value only for
 insert into a LONG column'' is raised when loading data into TextField
 (NCLOB) with ''python manage.py loaddata''

 Test Django project and steps to reproduce are here
 [https://github.com/hadalin/django-oracle-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/065.03fc56bc9c0af54fdc8de73a98a221c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

61 matches

Mail list logo