[Django] #18846: Error in serializing a Multi-table inherited model

[Django]

#18846: Error in serializing a Multi-table inherited model
--+-
 Reporter:  cheese|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Serialization)  |Version:  1.4
 Severity:  Normal|   Keywords:  Multi-table
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 I have Django 1.4.1 and Python 2.7.3 on Fedora 17 x86_64.

 The attached code should show the 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16211: using negated F()-expression in update query

[Django]

#16211: using negated F()-expression in update query
-+-
 Reporter:  wdoekes  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Basically, a review by anybody else than patch author is OK. See
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#ready-for-checkin]. A review isn't mandatory, but it will help
 the committer, and thus also help you to get the patch in.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18845: Runtime error in setting.py causes silent exception and empty apps list

[Django]

#18845: Runtime error in setting.py causes silent exception and empty apps list
-+-
 Reporter:  ac@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Management |Version:  1.4
  commands)  |   Keywords:  management installed
 Severity:  Normal   |  apps settings exception
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 I had a runtime error in my settings.py file that wasn't being reported.

 django/config/__init__.py : 94 was silently re-throwing, and[[BR]]
 django/core/management/__init__.py : 103 was setting the INSTALLED_APPS
 list to an empty array.

 I suggest the following changes:

 django/config/__init__.py : 94 : except Exception, e:[[BR]]
 django/core/management/__init__.py : 103 : sys.stdout.write('%s\n' % e)

 This will result in the following printed on execution of any management
 command:

 Could not import settings '.settings' (Is it on sys.path?):
 

 Thank you

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16211: using negated F()-expression in update query

[Django]

#16211: using negated F()-expression in update query
-+-
 Reporter:  wdoekes  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Who would need to review the patch?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
-+-
 Reporter:  ikelly   |Owner:  akaariai
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  oracle postgresql|  decision needed
  mysql schemas  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by net147):

 * cc: net147 (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 6786b3: Modified docs about SpatiaLite version that doesn'...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6786b38ace99dfa4db4f70d32249450771c3fa0f
  
https://github.com/django/django/commit/6786b38ace99dfa4db4f70d32249450771c3fa0f
  Author: Ramiro Morales 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M docs/ref/contrib/gis/install.txt
M docs/ref/contrib/gis/testing.txt

  Log Message:
  ---
  Modified docs about SpatiaLite version that doesn't need manual initial SQL 
file loading as per 675431dfaaa.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18747: Django admin list_display eats AttributeError by mistake

[Django]

#18747: Django admin list_display eats AttributeError by mistake
+--
 Reporter:  liu.dongyuan@…  |Owner:  thikonom
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  1.4
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by thikonom):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => thikonom
 * needs_docs:   => 0
 * has_patch:  0 => 1


Comment:

 Since i suppose the AttributeError is catched this way by design,
 i amended the code to distinguish between the Exception raise by the model
 itself or by any other object

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18840: Important upload_to parameter is missing from upload doc

[Django]

#18840: Important upload_to parameter is missing from upload doc
--+
 Reporter:  Tuttle|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 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 Tuttle):

 Of course, I confused the forms vs. models `FieldField` myself. :) Sorry
 for the noise.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6744: inspectdb doesn't set the primary_key/unique attribute on mixed case columns

[Django]

#6744: inspectdb doesn't set the primary_key/unique attribute on mixed case
columns
-+-
 Reporter:  fabiocorneti |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 AFAIK this is fixed for some time already.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18843: manage.py inspectdb raises TypeError for columns containing '%'

[Django]

#18843: manage.py inspectdb raises TypeError for columns containing '%'
-+-
 Reporter:  airstrike|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb,   |  Needs documentation:  0
  TypeError  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by claudep):

 I'm not absolutely sure to have fixed your precise problem. At least, the
 non-ascii chars stuff is the subject of ticket #16737.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18843: manage.py inspectdb raises TypeError for columns containing '%'

[Django]

#18843: manage.py inspectdb raises TypeError for columns containing '%'
-+-
 Reporter:  airstrike|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb,   |  Needs documentation:  0
  TypeError  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [f5ea730dac0986b2d48889a2d0fab2c5befb4494]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5ea730dac0986b2d48889a2d0fab2c5befb4494"
 Fixed #18843 -- Replaced more special chars in column names (inspectdb)

 Thanks airstrike for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f5ea73: Fixed #18843 -- Replaced more special chars in col...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f5ea730dac0986b2d48889a2d0fab2c5befb4494
  
https://github.com/django/django/commit/f5ea730dac0986b2d48889a2d0fab2c5befb4494
  Author: Claude Paroz 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M django/core/management/commands/inspectdb.py
M tests/regressiontests/inspectdb/models.py
M tests/regressiontests/inspectdb/tests.py

  Log Message:
  ---
  Fixed #18843 -- Replaced more special chars in column names (inspectdb)

Thanks airstrike for the report.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18844: Allow Oracle DatabaseWrapper to support session options extra kwargs as settings.DATABASE_OPTIONS

[Django]

#18844: Allow Oracle DatabaseWrapper to support session options extra kwargs as
settings.DATABASE_OPTIONS
--+
 Reporter:  fabio.theone@…|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:  oracle session
 Triage Stage:  Unreviewed|  options
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 It would be nice to support extra keyword arguments on
 backends.oracle.DatabaseWrapper to set session options like
 NLS_DATE_FORMAT, NLS_LANGUAGE, NLS_TERRITORY, etc. Some databases have
 different options and those are fixed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12460: inspectdb and field names ending with underscores

[Django]

#12460: inspectdb and field names ending with underscores
-+-
 Reporter:  3gun |Owner:  kgibula
 |   Status:  closed
 Type:  Bug  |  Version:  master
Component:  Core (Management |   Resolution:  fixed
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  inspectdb|  Patch needs improvement:  0
  underscore characters digits   |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [395c6083af93cc37c7d16ef4db451091841cefdc]:
 {{{
 #!CommitTicketReference repository=""
 revision="395c6083af93cc37c7d16ef4db451091841cefdc"
 Fixed #12460 -- Improved inspectdb handling of special field names

 Thanks mihail lukin for the report and elijahr and kgibula for their
 work on the patch.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 395c60: Fixed #12460 -- Improved inspectdb handling of spe...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 395c6083af93cc37c7d16ef4db451091841cefdc
  
https://github.com/django/django/commit/395c6083af93cc37c7d16ef4db451091841cefdc
  Author: Claude Paroz 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M django/core/management/commands/inspectdb.py
M tests/regressiontests/inspectdb/models.py
M tests/regressiontests/inspectdb/tests.py

  Log Message:
  ---
  Fixed #12460 -- Improved inspectdb handling of special field names

Thanks mihail lukin for the report and elijahr and kgibula for their
work on the patch.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8754: PYTHONPATH not passed through to regressiontests/admin_scripts/AdminScriptTestCase.run_test()

[Django]

#8754: PYTHONPATH not passed through to
regressiontests/admin_scripts/AdminScriptTestCase.run_test()
-+-
 Reporter:  Richard Davies   |Owner:  nobody
   |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I just hit this issue, I ran tests using this setup:
 {{{
 cd tests
 ln -s ../django django
 ./runtests --settings=test_sqlite admin_scripts
 }}}
 However, the tests use my system's Django, not the django from
 tests/django. Using virtualenv for test setup fixed this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16715: Wrong JOIN with nested null-able foreign keys

[Django]

#16715: Wrong JOIN with nested null-able foreign keys
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  join, values,|  checkin
  nested, foreign key, null-able |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I have made some final adjustments to the patch. Now there is logic to
 make sure that we never generate join chains like a LOUTER b INNER c,
 which will result in broken queries.

 I tested this with adding this little test to sql/compiler.py
 get_from_clause():
 {{{
 for alias in self.query.tables:
 +if alias in self.query.alias_map:
 +cur_alias = self.query.alias_map[alias]
 +if cur_alias.join_type == self.query.INNER:
 +parent_alias =
 self.query.alias_map[cur_alias.lhs_alias]
 +assert parent_alias.join_type != self.query.LOUTER
 }}}
 This test fails when running queries tests on master (that is, we have
 join chains like a LOUTER b INNER c). After patch there isn't such join
 chains anymore in the whole test suite.

 I am still leaving a day or so for review if somebody wants to do that.
 The patch is
 
[https://github.com/akaariai/django/commit/33cffe978afcec292f59117d788e158d7bfbf094
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18843: manage.py inspectdb raises TypeError for columns containing '%'

[Django]

#18843: manage.py inspectdb raises TypeError for columns containing '%'
-+-
 Reporter:  airstrike|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb,   |  Needs documentation:  0
  TypeError  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by claudep):

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


Comment:

 I plan to commit first #12460, then it should be easier to fix this one.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by rodolfo_3):

 Just set managed=False don't solve the problem on tests. Between every
 test case, django executes a sql_flush() to all tables. When do it for a
 view, an exception is raised. To use this solution, another patch is
 needed, changing the behavior of the "sql_flush" method of the mysql
 backend.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by rodolfo_3):

 The PostgreSQL code are explicitly asking for views, but it isn't true on
 sqlite3:
 {{{
   SELECT name FROM sqlite_master
   WHERE type='table' AND NOT name='sqlite_sequence'
   ORDER BY name
 }}}

 To return views using sqlite3, the "where" clause needs to be changed to
 something like
 {{{
   type in ('table', 'view') and not name='sqlite_sequence'
 }}}

 The oracle backend return just tables, ignoring views:
 {{{
   SELECT TABLE_NAME FROM USER_TABLES
 }}}


 Replying to [comment:3 akaariai]:
 > I wonder if the approach here is correct, or if it would cause further
 problems. The PostgreSQL code does this in get_table_list():
 > {{{
 > SELECT c.relname
 > FROM pg_catalog.pg_class c
 > LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
 > WHERE c.relkind IN ('r', 'v', '')
 > AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
 > AND pg_catalog.pg_table_is_visible(c.oid)
 > }}}
 >
 > The c.relkind in ('r', 'v', `''`) says that we are explicitly asking for
 views, too... So, before committing this we should make clear if we want
 views or not from get_table_list(), and then make sure we are consistent
 on all backends.
 >
 > IMHO the problem reported in this ticket is caused by having an
 unmanaged view used by a managed model. It might be better to do a hack
 and change the model._meta.managed to False in the post_sync() signal.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18843: manage.py inspectdb raises TypeError for columns containing '%'

[Django]

#18843: manage.py inspectdb raises TypeError for columns containing '%'
+--
 Reporter:  airstrike   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  1.4
 Severity:  Normal  |   Keywords:  inspectdb,
 Triage Stage:  Unreviewed  |  TypeError
Easy pickings:  1   |  Has patch:  0
|  UI/UX:  0
+--
 > python manage.py inspectdb --database=foo

 class Foobar(models.Model):
 TypeError: not enough arguments for format string

 I've since inspected the database and spotted fields such as...

 "PARTIC _(%)_PRÉ"
 "Participação_de_Recarga_no_GROSS_(%)"

 ...which I believe are causing this 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
-+
 Reporter:  ckarrie  |Owner:  jbronn
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgis 2.0  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by fcurella):

 Looking at the data closer, seems like there's a precision/rounding issue.

 For both failures, the expected value contains
 `UNIT["degree",0.0174532925199433`, but we get a more accurate
 `UNIT["degree",0.01745329251994328`.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18829: ModelChoiceIterator returns the queryset length when

[Django]

#18829: ModelChoiceIterator returns the queryset length when
-+-
 Reporter:  facundo.olano@…  |Owner:  thikonom
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  ModelChoiceIterator  | Triage Stage:
  ModelForm  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by thikonom):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10852: Add no-fuzzy-matching option to makemessages

[Django]

#10852: Add no-fuzzy-matching option to makemessages
-+-
 Reporter:  graham.carlyle@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  master
  Internationalization   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 Just wanted to chime in with a "me too".

 Replying to [comment:3 ramiro]:
 > Exactly, the entries marked as fuzzy by `msgmerge` are generated by a
 simple lexicographic comparison and the probability of them being not
 totally accurate is high

 At least in my case, this is just not true. It's filling things in that
 are similar but not the same, and it shouldn't be. I'd rather they be
 empty than speculatively filled in.

 There are already many options available for makemessages. I really don't
 see the harm in adding another option.

 For now, I'm patching Django locally, which I really hate to do.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mrmachine):

 Updated this patch with some minor tweaks arising from IRC discussion with
 akaariai. Consume generator content on access, not assignment, so that
 generator content can still stream if no middleware has to access
 `response.content`. Raise `PendingDeprecationWarning` if you explicitly
 create an `HttpResponse` with `streaming_content=True` and then you (or
 some middleware) accesses `response.content`.

 Also see recent google developers discussion at
 https://groups.google.com/d/topic/django-developers/RrNPfuJxnlM/discussion

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18829: ModelChoiceIterator returns the queryset length when

[Django]

#18829: ModelChoiceIterator returns the queryset length when
-+-
 Reporter:  facundo.olano@…  |Owner:  thikonom
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  ModelChoiceIterator  | Triage Stage:
  ModelForm  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by thikonom):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * owner:  nobody => thikonom
 * needs_docs:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #5805: Specify multicolumn indexes.

[Django]

#5805: Specify multicolumn indexes.
-+-
 Reporter:  Stavros  |Owner:  jgelens
  Korokithakis|   Status:  assigned
 Type:  New feature  |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  index multicolumn|  Patch needs improvement:  0
  indexes database dceu2011  |UI/UX:  0
Has patch:  1|
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by dbrgn):

 * cc: dbrgn (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18790: Non-ascii characters in password for database settings don't work

[Django]

#18790: Non-ascii characters in password for database settings don't work
-+-
 Reporter:  thcourbon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  unicode  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 Someone should test it with oracle to see if the password encoding is also
 needed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18790: Non-ascii characters in password for database settings don't work

[Django]

#18790: Non-ascii characters in password for database settings don't work
-+-
 Reporter:  thcourbon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  unicode  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 Note also that psycopg2 < 2.4.3 will also choke on spaces, backslashes or
 quotes.[[BR]]
 http://psycopg.lighthouseapp.com/projects/62710/tickets/87
 -psycopg2connect-fails-when-using-spaces-in-password-keyword [[BR]]
 https://dndg.it/cgi-
 
bin/gitweb.cgi?p=public/psycopg2.git;a=commit;h=625cc1b402b33799757fb9b8fe421a2ea63e1236

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DATE_INPUT_FORMATS   | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by clay.evil@…):

 ok, sorry don't waset your time, i did find a solution, all my fault.
 sorry to bothered thou.

 if anyone is intereds, this strings are working for me:
 DATE_INPUT_FORMATS = (
 '%-d. %-m. %Y', '%-d. %-m. %y',
 '%-d.%-m.%Y', '%-d.%-m.%y',
 '%Y-%-d-%-m', '%y-%-d-%-m',
 '%-d/%-m/%Y', '%-d/%-m/%y',
 '%d. %m. %Y','%d. %m. %y',
 '%d.%m.%Y', '%d.%m.%y',
 '%Y-%m-%d', '%y-%d-%m',
 '%d/%m/%Y', '%d/%m/%y',
 '%d %b %Y', '%d %b, %Y', '%B %d %Y',
 '%B %d, %Y', '%d %B %Y', '%d %B, %Y')

 + i did corrent a mystake in my code in the HumanTextInput, which sloud be
 named HumanDateInput and inherit from forms.DateInput, like this:

 class HumanDateInput(forms.DateInput):
 def _format_value(self, value):
 logger.debug("_format_value:%s", value)
 if value == date.today():
 return ugettext("__cal_today__")
 elif value == (date.today() + timedelta(days=1)):
 return ugettext("__cal_tomorrow__")
 return super(HumanTextInput, self)._format_value(value)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DATE_INPUT_FORMATS   | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 sorry, using my code above django formats the input as "Y-%m-%d" i.e.
 2012-08-17, i don't know why yet. but i don't want to miss lead you. i
 just found out...

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DATE_INPUT_FORMATS   | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 First, my apologies, you're both right, the docs states it uses strftime.

 But i have another problem with this.
 Django displays the format wrong, but it is albe parse it very well. If i
 enter 1. 1. 2012 in the filed, it gets parsed. So its seems that django
 uses somethign else to display and to parse the input.

 The problem is, i strftime according to doc has not any letter for days or
 month without leasing zeros, but i did google that if you put "-" before
 the format letters, its strips the leading zeros. i.e. "-d. -m. Y".
 This works well sice the input filed is rendered properly without leading
 zeros BUT it cannot parse the input on submit.


 So to summarize:

 if i use '%j. %n. %Y' the input gets parsed well, but is rendered
 incorrectly

 if i use "-d. -m. Y". the inputs renders correctly, but gets not parsed.


 ---

 I know that  "-d. -m. Y" is not documented in python. But is there a way
 to get working at least one of the format string?


 ---

 Also, in my project i didnt notice this issue as i use custom fileds and
 widgets in my projects

 class HumanTextInput(TextInput):
 def _format_value(self, value):
 logger.debug("_format_value:%s", value)
 if value == date.today():
 return ugettext("__cal_today__")
 elif value == (date.today() + timedelta(days=1)):
 return ugettext("__cal_tomorrow__")
 return super(HumanTextInput, self)._format_value(value)


 class HumanDateFiled(forms.DateField):
 def to_python(self, value):
 if value == ugettext("__cal_today__"):
 return date.today()
 elif value == ugettext("__cal_tomorrow__"):
 return date.today() + timedelta(days=1)
 return super(HumanDateFiled, self).to_python(value)

 class NewsModuleArticleForm(InstawebModelForm):
 pub_date =
 HumanDateFiled(label=_("__field_article_publish_date__"),
 widget=HumanTextInput, initial=date.today)

 This way a user can type "today" or "tomorrow" in the input fields. a
 small feature in out project. However, this way, i can use the '%j. %n.
 %Y' format string in DATE_INPUT_FORMATS and everything works well.. except
 django admin..

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18182: Raw password echoed on authentication if no hashing used

[Django]

#18182: Raw password echoed on authentication if no hashing used
--+
 Reporter:  danielr   |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.4
 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 robertomaurizzi):

 What is the recommended way to fix an auth_user table full of "non
 passwords" as created following the provided code sample for an external
 authentication handler from
 https://docs.djangoproject.com/en/dev/topics/auth/#writing-an-
 authentication-backend ?
 I'm planning to migrate an application to 1.4.1 and all my users have a
 'nice' "password read from legacy_passwd table"...
 What is the correct procedure to set all users without a valid password to
 an invalid password? Moreover: it'd be nice to update the sample for about
 external authentication... :-)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17365: Extend test discovery to include unittest2 test suite runner

[Django]

#17365: Extend test discovery to include unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  myusuf3
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by luizvital):

 * cc: luiz.vital@… (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DATE_INPUT_FORMATS   | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kmtracey):

 The problem is j and n don't mean what is stated here, in the context
 where they are trying to be used. The doc for DATE_INPUT_FORMATS
 (https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-
 DATE_INPUT_FORMATS) states:

 Note that these format strings use Python's datetime module syntax, not
 the format strings from the date Django template tag.

 That links to the Python datetime module syntax:
 http://docs.python.org/library/datetime.html#strftime-strptime-behavior
 where j is "   Day of the year as a decimal number [001,366]." an n has no
 meaning.

 The meanings stated appear to come from
 https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std
 :templatefilter-date. As noted above those output formatting strings are
 not what's used for the input format specifications. Yes, this is a bit
 weird and inconsistent but there's not much that can be done about it now.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DATE_INPUT_FORMATS   | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 The documentation explains that DATE_INPUT_FORMATS format strings use
 Python's datetime module syntax.[[BR]]
 http://docs.python.org/library/datetime.html#strftime-strptime-behavior

 %j  Day of the year as a decimal number [001,366].[[BR]]
 %n is not mentioned.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18842: Calling "manage.py reset " causes infinite loop

[Django]

#18842: Calling "manage.py reset " causes infinite loop
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  manage.py reset  |  Unreviewed
  mysql arch |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Core (Other) => Core (Management commands)


Comment:

 The backtrace shows that the process is blocked because it waits for a
 reply from the MySQL server. That, and your other comments, point at a
 problem of your MySQL server rather than of Django.

 In addition, the problem is hard to reproduce; it looks more like a quirk
 of your system than a bug in Django.

 If you can reproduce the problem at least on another system, please
 provide as much information as possible and reopen this ticket. In the
 current state of things, there's not much we can do -- sorry.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18842: Calling "manage.py reset " causes infinite loop

[Django]

#18842: Calling "manage.py reset " causes infinite loop
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  manage.py reset  | Triage Stage:
  mysql arch |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


Comment:

 Update: restarting the mysql daemon and killing the python2 process
 resolves the problem temporarily.
 The infinite loop thing occurs randomly, but not every time...

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18840: Important upload_to parameter is missing from upload doc

[Django]

#18840: Important upload_to parameter is missing from upload doc
--+
 Reporter:  Tuttle|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 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 kmtracey):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 It would be out-of-place and confusing to say anything about `upload_to`
 near where the quoted snippet appears in the documentation, because that
 snippet concerns a plain form, not a model form, and putting `upload_to`
 on the `forms.FileField` would be an error. `upload_to` is a required
 parameter of `models.FileField`, and its documentation clearly notes that
 
(https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField).
 Where `upload_to` could be mentioned in the referenced doc is:
 https://docs.djangoproject.com/en/dev/topics/http/file-uploads/#handling-
 uploaded-files-with-a-model. Something could be added in those first two
 sentences noting that the `models.FileField` `upload_to` parameter
 controls where the file will be saved.

 I don't think it would be appropriate to add any mention of `upload_to` to
 the forms field reference, as it is not a parameter of the forms-level
 `FileField`.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18842: Calling "manage.py reset " causes infinite loop

[Django]

#18842: Calling "manage.py reset " causes infinite loop
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.4
 Severity:  Normal|   Keywords:  manage.py reset mysql arch
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When calling manage.py reset  on a django project the script
 seems to get stuck in an infinite loop, never completing the operation.
 I've even let it run for a few hours straight, but it never finished. The
 exact same project seems to be working on a fellow developer's system
 (Arch Linux), with the same python version (2.7.3).

 Giving an interrupt signal the following call stack trace is printed:
 {{{
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 443, in
 execute_from_command_line
 utility.execute()
   File "/usr/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 382, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 196, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 232, in execute
 output = self.handle(*args, **options)
   File "/usr/lib/python2.7/site-packages/django/core/management/base.py",
 line 304, in handle
 app_output = self.handle_app(app, **options)
   File "/usr/lib/python2.7/site-
 packages/django/core/management/commands/reset.py", line 51, in handle_app
 cursor.execute(sql)
   File "/usr/lib/python2.7/site-packages/django/db/backends/util.py", line
 40, in execute
 return self.cursor.execute(sql, params)
   File "/usr/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 114, in execute
 return self.cursor.execute(query, args)
   File "/usr/lib/python2.7/site-packages/MySQLdb/cursors.py", line 161, in
 execute
 r = self._query(query)
 KeyboardInterrupt

 }}}

 After the keyboard interrupt, the phpmyadmin interface also has difficulty
 loading. Somehow the bug seems to affect the sql daemon.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %y')

[Django]

#18841: djnago admin date fileds messed up when using DATE_INPUT_FORMATS = ('%j.
%n. %Y', '%j. %n. %y')
---+--
 Reporter:  clay.evil@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.4
 Severity:  Normal |   Keywords:  DATE_INPUT_FORMATS admin
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 when i set DATE_INPUT_FORMATS = ('%j. %n. %Y', '%j. %n. %Y',) for my
 project, it seems that django admin somehow cannot display date fields
 properly and also the javascript calendar is not working. "j" = days
 without leading zeros, and "n" = months without leading zeros.

 is there an easy way to disable i18n in django admin until this bug is
 resolved?

 Thank you.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14658: DateField initial does not honor locale, against documentation

[Django]

#14658: DateField initial does not honor locale, against documentation
+
 Reporter:  intgr   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.2
 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 nferrari):

 Hi,

 I didn't take time to patch Django yet but here's the trick to have a
 forms.DateField localized initial value:

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
   date = forms.DateField(initial=lambda:
 django.utils.formats.localize_input(datetime.date.today()))
   }}}
 }}}

 Regards,

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I don not see any drawback of returning a namedtuple with "tablename
 is_view" (or type instead of is_view) as return values. This is internal
 API and we can alter it as we wish. Also, automatically inspecting views
 as non-managed would be good. Maybe with a flag to inspectdb to only
 inspect tables/views/both.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18798: Redefinition of test test_get_language_from_path in tests.regressiontests.i18n.tests

[Django]

#18798: Redefinition of test test_get_language_from_path in
tests.regressiontests.i18n.tests
-+-
 Reporter:  void |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:   |   Resolution:  fixed
  Internationalization   | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [10d32072afa1e1d4391108191800ce7007a63f2e]:
 {{{
 #!CommitTicketReference repository=""
 revision="10d32072afa1e1d4391108191800ce7007a63f2e"
 Fixed #18798 -- Renamed conflicting test methods in i18n tests
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 10d320: Fixed #18798 -- Renamed conflicting test methods i...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 10d32072afa1e1d4391108191800ce7007a63f2e
  
https://github.com/django/django/commit/10d32072afa1e1d4391108191800ce7007a63f2e
  Author: Alexey Boriskin 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Fixed #18798 -- Renamed conflicting test methods in i18n tests



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18678: HTTPResponse subclasses don't accept base class parameters

[Django]

#18678: HTTPResponse subclasses don't accept base class parameters
---+
 Reporter:  hp1337@…   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Claude Paroz ):

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


Comment:

 In [44c09de555f83b0596a0886e3f51a9a84368d036]:
 {{{
 #!CommitTicketReference repository=""
 revision="44c09de555f83b0596a0886e3f51a9a84368d036"
 Fixed #18678 -- HttpResponse init arguments allowed for subclasses

 Thanks hp1...@gmail.com for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 44c09d: Fixed #18678 -- HttpResponse init arguments allowe...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 44c09de555f83b0596a0886e3f51a9a84368d036
  
https://github.com/django/django/commit/44c09de555f83b0596a0886e3f51a9a84368d036
  Author: Claude Paroz 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M django/http/__init__.py
M docs/ref/request-response.txt
M tests/regressiontests/httpwrappers/tests.py

  Log Message:
  ---
  Fixed #18678 -- HttpResponse init arguments allowed for subclasses

Thanks hp1...@gmail.com for the report.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by claudep):

 I was only referring to inspectdb for the automatic managed flag. I do
 agree that for other parts of the code, it is the user's responsability to
 set it correctly. However, there might be other use cases where the table
 vs view distinction might be useful.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18840: Important upload_to parameter is missing from upload doc

[Django]

#18840: Important upload_to parameter is missing from upload doc
---+
 Reporter:  Tuttle |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The file uploads topic and even ref page don't mention the `upload_to`
 parameter that is '''required''':

 * https://docs.djangoproject.com/en/dev/topics/http/file-uploads/
 * https://docs.djangoproject.com/en/dev/ref/forms/fields/

 If the newbie follows the top example on the topic page:

 {{{
 class UploadFileForm(forms.Form):
 title = forms.CharField(max_length=50)
 file  = forms.FileField()
 }}}

 he or she is immediatelly confused by the model validation 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18839: Field.__init__() should call super() at end.

[Django]

#18839: Field.__init__() should call super() at end.
---+
 Reporter:  applegrew  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Currently `django.forms.Field.__init__()` does not invoke `super()` at the
 end. This causes problem when trying to inherit `Field` along with other
 classes. So, in

 {{{#!python
 class C(A, forms.Field, B):
 }}}

 In the above `__init__()` of `B` will not get called because of this bug.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18838: upgrade to 1.3.2

[Django]

#18838: upgrade to 1.3.2
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 Please read TicketClosingReasons/UseSupportChannels

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I do like the idea of setting automatically managed=False for existing
 views. The problem I see with this approach is that this goes somewhat
 against the philosophy of Django - we do not alter the models based on
 inspection, we trust the models to be correct. So, on that basis a light
 -0 on this approach. One of the worries is that we would need to
 consistently set the managed flag in app loading, not only in syncdb/flush
 etc.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 03671a: Reordered imports

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 03671ad7e30749ecde70a7af04fff0b57476b1e0
  
https://github.com/django/django/commit/03671ad7e30749ecde70a7af04fff0b57476b1e0
  Author: Aymeric Augustin 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M django/utils/text.py

  Log Message:
  ---
  Reordered imports

to avoid an error introduced in 5301a9d7b1.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18791: [py3] Double import of six in django.forms.widgets

[Django]

#18791: [py3] Double import of six in django.forms.widgets
-+-
 Reporter:  void |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Python 3 |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1"
 [py3] Removed duplicate imports.

 Fixed #18837. Refs #18791.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18837: [py3] Double import of six in django.forms.models

[Django]

#18837: [py3] Double import of six in django.forms.models
--+
 Reporter:  void  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Python 3  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Aymeric Augustin ):

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


Comment:

 In [5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1"
 [py3] Removed duplicate imports.

 Fixed #18837. Refs #18791.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5301a9: [py3] Removed duplicate imports.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1
  
https://github.com/django/django/commit/5301a9d7b1c2151e9b0496c7e244e8ceb6d273c1
  Author: Aymeric Augustin 
  Date:   2012-08-23 (Thu, 23 Aug 2012)

  Changed paths:
M django/contrib/gis/db/models/query.py
M django/db/backends/oracle/base.py
M django/forms/models.py
M django/utils/text.py

  Log Message:
  ---
  [py3] Removed duplicate imports.

Fixed #18837. Refs #18791.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18838: upgrade to 1.3.2

[Django]

#18838: upgrade to 1.3.2
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.3
 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 f.ali@…):

 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18838: upgrade to 1.3.2

[Django]

#18838: upgrade to 1.3.2
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hello,

 I would like to know the steps on how to upgrade my current django version
 to 1.3.2 for particular domain in my server

 Thanks

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18837: [py3] Double import of six in django.forms.models

[Django]

#18837: [py3] Double import of six in django.forms.models
--+
 Reporter:  void  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Python 3  |  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 aaugustin):

 * needs_better_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report.

 A similar problem was reported in #18791. I suspect it's a side effect of
 an automated refactoring.

 It happens in a four files:

 {{{
 % grep 'from django.utils import six' **/*.py | uniq -c | grep -v '^   1 '
3 django/contrib/gis/db/models/query.py:from django.utils import six
2 django/db/backends/oracle/base.py:from django.utils import six
2 django/forms/models.py:from django.utils import six
2 django/utils/text.py:from django.utils import six
 }}}

 I will commit a fix shortly.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18837: [py3] Double import of six in django.forms.models

[Django]

#18837: [py3] Double import of six in django.forms.models
-+-
 Reporter:  void |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Python 3 |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by void):

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


Comment:

 I've created pull request here:
 [https://github.com/django/django/pull/300]

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18782: database "view" treated as "table" on flush (mysql)

[Django]

#18782: database "view" treated as "table" on flush (mysql)
-+-
 Reporter:  rodolfo_3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql introspection  |  Needs documentation:  0
  table view |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by claudep):

 It might be that this specific ticket could be solved with the tip given
 by akaariai. But generally, I think we should make it more clear. For
 example, we could add a keyword parameter to get_table_list (maybe
 table_names too), `with_views`. Or return a tuple (table_name, type) so
 client code can then act depending on type. For example, inspectdb could
 automatically set the managed flag to False for views.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #18837: [py3] Double import of six in django.forms.models

[Django]

#18837: [py3] Double import of six in django.forms.models
--+
 Reporter:  void  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Python 3  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is a double import of six in django.forms.models:
 {{{
 from django.utils import six
 from django.utils.text import get_text_list, capfirst
 from django.utils.translation import ugettext_lazy as _, ugettext
 from django.utils import six
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.