[Django] #21743: formset prefix attribute and formset empty form "__prefix__" don't refer to the same thing

[Django]

#21743: formset prefix attribute and formset empty form "__prefix__" don't 
refer to
the same thing
--+
 Reporter:  bjb@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  1.6
 Severity:  Normal|   Keywords:  formset prefix
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The formset `prefix` attribute and formset emptyform "!__prefix!__"
 placeholder don't refer to the same thing

 Formsets allow you to change the word "form" in the ids of the elements in
 the form to some other string, and the way you do that is with the
 "prefix" kwarg when creating the FormsetFactory.  eg, `id_form-5_id` ->
 `id_note-5_id` when prefix = note.  That's good.

 Formsets have a way to generate an empty form so you can add new forms
 into your html with simple javascript, you don't have to know what all the
 fields are in javascript - just clone the empty form (and adjust the ids
 and fix up the TOTAL_FORMS etc).  That's good.

 Unfortunately, the placeholder for the form number in the ids of the empty
 form elements is called `__prefix__`.  That is confusing, because the
 prefix passed in to the formset is used in the ids in a different spot.

 `id_note-__prefix__-id`, where "note" was passed in as the value for the
 prefix kwarg.

 I think the !__prefix!__ placeholder should be changed to some other
 string, like "formnum".

 An emptyform with no prefix specified would then look like:  `id_form-
 __formnum__-id`

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.937fdae7dd4af7e3618c00e0405e942b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21742: Unable to prevent creation of a database during test runs

[Django]

#21742: Unable to prevent creation of a database during test runs
---+
 Reporter:  yscumc |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  1.5
 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 yscumc):

 Another possibility is to have a more flexible option:
 {{{
 DATABASES = {
 'default': {
 ...
 },
 'someotherdb': {
 ...
 'TEST_SEPARATE_DATABASE': True,
 },
 }
 }}}

 - `'TEST_SEPARATE_DATABASE': True`: The default (current) behavior which
 creates a separate test database and modifies the db connection
 - `'TEST_SEPARATE_DATABASE': None`: The behavior described in the ticket
 above which will remove the database from the db connections
 - `'TEST_SEPARATE_DATABASE': False`: This should leave the db connection
 unchanged during `setup_databases()`, allowing for the unit tests to query
 the regular database. However, the Django test case classes would have to
 be updated to prevent the regular database from being wiped on each run.
 It may not be the best design for tests to depend on live data, but if the
 test was carefully coded, it should work well. This would alleviate the
 need for a separate test database server to be set up and mock fixtures to
 be created if only simple reads are done in the tests.

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

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

Re: [Django] #21742: Unable to prevent creation of a database during test runs

[Django]

#21742: Unable to prevent creation of a database during test runs
---+
 Reporter:  yscumc |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Testing framework  |  Version:  1.5
 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 mjtamlyn):

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


Comment:

 This seems a reasonable use case to me.

-- 
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.194939bf9abd89a81fa1452911cacb27%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21742: Unable to prevent creation of a database during test runs

[Django]

#21742: Unable to prevent creation of a database during test runs
---+
 Reporter:  yscumc |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Testing framework  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have two databases set up as follows:


 {{{
 DATABASES = {
 'default': {
 ...
 },
 'someotherdb': {
 ...
 },
 }
 }}}

 I do not have write access to `someotherdb` and would like to prevent the
 creation of a test database for `someotherdb` when my tests run. However,
 this simple scenario doesn't seem to be possible.

 I believe Django would would greatly benefit from having another option
 for the database dict such as the following:
 {{{
 DATABASES = {
 'default': {
 ...
 },
 'someotherdb': {
 ...
 'TEST_CREATE_DATABASE': False,
 },
 }
 }}}
 If set, `DjangoTestSuiteRunner.setup_databases()` and
 `DjangoTestSuiteRunner.teardown_databases()` should delete the database
 from the `django.db.connections` so it cannot be accessed from the unit
 tests. It should prevent an error from being raised upon trying to run
 test cases which do not use the read-only database.


 

 In an attempted workaround, subclassing `DjangoTestSuiteRunner` as in
 http://stackoverflow.com/questions/5917587/django-unit-tests-without-a-db
 doesn't work because I need to use the `default` database in my test.
 Using this method, if I want to use the `default` database, but not
 `someotherdb`, I would probably have to copy and paste most of the code
 from `DjangoTestSuiteRunner.setup_databases()` even after subclasssing
 `DjangoTestSuiteRunner`. It also doesn't make sense to have to do all this
 just to prevent a test database from being created.

 I then tried the following, but it doesn't seem to work because of perhaps
 a pesky bug:
 {{{
 DATABASES = {
 'default': {
 'NAME': 'mydefaultdb',
 ...
 },
 'someotherdb': {
 'NAME': 'theotherdb',
 ...
 'TEST_MIRROR': 'default',
 },
 }
 }}}
 It still connect to the server for `someotherdb` and attempts to open the
 non-existent database `test_mydefaultdb`, which of course fails because it
 is supposed to be on the server for `default`.

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

Re: [Django] #21680: Stop supporting models in non-installed apps

[Django]

#21680: Stop supporting models in non-installed apps
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  app-loading   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 I'm going to implement a deprecation path for this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.fdf256489558e86ea21738e48f00239b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21741: render_to_string without providing a dictionary still puts a dictionary into the context

[Django]

#21741: render_to_string without providing a dictionary still puts a dictionary
into the context
-+
 Reporter:  Keryn Knight   |  Owner:  nobody
 Type:  Cleanup/optimization | Status:  new
Component:  Template system  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 given the following scenario:
 {{{
 >>> from django.template.loader import render_to_string
 >>> from django.template import Context
 >>> render_to_string('file.extension', context_instance=Context())
 >>> # or ...
 >>> render_to_string('file.extension')
 }}}
 where a dictionary is explicitly not being provided, the final context
 given to the template when `render()` is called will have `{}` as the last
 of the `.dicts`

 The reason is because if
 
[https://github.com/django/django/blob/fe995e6cbdcf2766cf0aa951c8ef4549ad27694c/django/template/loader.py#L167
 none is provided], a new dict is created, and then it is provided to the
 context instance
 
([https://github.com/django/django/blob/fe995e6cbdcf2766cf0aa951c8ef4549ad27694c/django/template/loader.py#L173
 1],
 
[https://github.com/django/django/blob/fe995e6cbdcf2766cf0aa951c8ef4549ad27694c/django/template/loader.py#L176
 2]) without checking the dict's `len()`

 Marking as cleanup/optimization because it doesn't cause any problems (the
 only one being: it appears in debug_toolbar), but providing the ticket at
 least means the option is there to change it, and a history of why not to
 change it exists if ''wontfix'd'' (which may be the best course of action,
 on balance, but that's not for me to say)

-- 
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/080.6f4a39079727a6b1b246e2980acdf134%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by mjtamlyn):

 I ran some tests with that commit. The good news is that python 3.4b2
 seems to be fine - the only failures now are the egg loading related
 failures and (obviously) the tests for saferef. There were no nasty
 warnings in interpreter shutdown. A number of other warnings have also
 disappeared, although not when you run with `-Wall`.

 The bad news is that python 2.7 doesn't work very well. Basically all the
 tests in `dispatch.tests` fail. https://gist.github.com/mjtamlyn/8304266.
 The same errors also happen on py3.3.

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

Re: [Django] #21739: When running tests, the fixture loading process has verbosity = 0 hardcoded

[Django]

#21739: When running tests, the fixture loading process has verbosity = 0 
hardcoded
-+-
 Reporter:  camilo.lopez.a@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  test fixture | Triage Stage:  Accepted
  verbosity  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by camilo.lopez.a@…):

 If I give a command verbosity = X, I expect every procedure inside it to
 use that level of verbosity. If not, you will break consistency.

-- 
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.47e00651f5ebc2dcea15eb34cb3afb17%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10811: Assigning unsaved model to a ForeignKey leads to silent failures

[Django]

#10811: Assigning unsaved model to a ForeignKey leads to silent failures
-+-
 Reporter:  Glenn|Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 ok i realized that i did something wrong, the problem still exists.

-- 
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.308ecdb202a58d50902e1392f3e6320a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21739: When running tests, the fixture loading process has verbosity = 0 hardcoded

[Django]

#21739: When running tests, the fixture loading process has verbosity = 0 
hardcoded
-+-
 Reporter:  camilo.lopez.a@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  test fixture | Triage Stage:  Accepted
  verbosity  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 I'm not sure it's a good idea to make fixture loading inherit `verbosity`
 from the `test` command. However, failure during loading fixtures should
 be loudly visible.

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

Re: [Django] #21739: When running tests, the fixture loading process has verbosity = 0 hardcoded

[Django]

#21739: When running tests, the fixture loading process has verbosity = 0 
hardcoded
-+-
 Reporter:  camilo.lopez.a@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  test fixture | Triage Stage:
  verbosity  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mjtamlyn):

 models.py will not be required in 1.7. That said, the ticket is still a
 reasonable 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/082.418615ae3b9e1e704416c4ef27b267f2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21739: When running tests, the fixture loading process has verbosity = 0 hardcoded

[Django]

#21739: When running tests, the fixture loading process has verbosity = 0 
hardcoded
-+-
 Reporter:  camilo.lopez.a@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  test fixture | Triage Stage:
  verbosity  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by camilo.lopez.a@…):

 The issue with the fixtures was that I hadn't a models.py file in my app,
 so all the fixtures where not recognized and it was filing silently.
 I discovered the issue debugging on the source code of Django. I changed
 verbosity from 0 to 2 and was able to realise what was going on.

 The models.py thing should be documented or better, change that behavior
 to just read from installed apps as one will expect.
 call_command should inherit verbosity from the test command.

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

Re: [Django] #21739: When running tests, the fixture loading process has verbosity = 0 hardcoded

[Django]

#21739: When running tests, the fixture loading process has verbosity = 0 
hardcoded
-+-
 Reporter:  camilo.lopez.a@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:  test fixture | Triage Stage:
  verbosity  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Could you tell us what the issue with your fixtures is, and what is the
 output when verbosity > 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.5719df6fd356df583f1bd6b7478268f3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21737: ImproperlyConfigured hidden, which causes hard to debug errors

[Django]

#21737: ImproperlyConfigured hidden, which causes hard to debug errors
--+
 Reporter:  apollo13  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Uncategorized |  Version:  master
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:  app-loading   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Thanks, your solution is more elegant.

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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by apollo13):

 And I got rid of saferef completely:
 
https://github.com/apollo13/django/commit/7a6c28977bf258b27c5bc2a19417f913c541e2dd
 -- Please test as much as possible :)

-- 
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.73e1766c2e6f6c5d3a70cc79ab494422%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.