Re: [Django] #31467: Possible error in the doc "Writing your first Django app, part 1".

[Django]

#31467: Possible error in the doc "Writing your first Django app, part 1".
-+-
 Reporter:  Marc-Antoine Daneau  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.0
 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 Marc-Antoine Daneau):

 * cc: Marc-Antoine Daneau (added)


Comment:

 Thank you for the reply. And in fact, of course I missed it, because it is
 not in the doc.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ae6f925cc8c538d0733ddcb19532b6c8%40djangoproject.com.

Re: [Django] #31416: FieldError when migrating field to new model subclass.

[Django]

#31416: FieldError when migrating field to new model subclass.
---+
 Reporter:  Eduard Anghel  |Owner:  Nan Liu
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Nan Liu):

 Replying to [comment:17 Adam (Chainz) Johnson]:
 > Hi @nanliu
 >
 > I believe the test for this should be in `test_autodetector.py`. The
 tests there don't create whole migrations. They make assertions on the
 output operations.
 >
 > Check out the test I wrote for a similar ticket in
 https://github.com/django/django/pull/12313/files#diff-
 c11e6432df7086eda3dfb9ab8e5b2839 , and those around that. They set up the
 before and after model states, ask the autodetector to find the operations
 through `get_changes()`, then make assertions on the operations.
 >
 > The "before" model states describe the state of the models before the
 change, which would be pulled from the migration history - in this case
 where just `Readable` exists. The "after" states describe the state the
 current model state, which would be pulled from the apps' model definitios
 - in this case, `Readable` with no fields and `Book` with the `title`
 field.
 >
 > When writing a test, please try use the predefined model states to
 reduce memory usage.
 >
 > Hope that helps you write a test. Once there's a failing test it should
 be easier to try find the fix.

 So, my code should be correct by using `self.get_changes([Readable],
 [Readable with no fields, Book, Magazine])`. but my code meant to fix this
 issue wasn't executed when I use `self.get_changes` while doing two
 separate migrations will execute my added code, which is confusing. Also I
 suspect that the first migration will construct a `loader.graph` that will
 reorder the action operations.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.13c67a4800ee20d5cdcdaabccc907901%40djangoproject.com.

Re: [Django] #31478: Template.get_exception_info relies on internal state which isn't correct for sub-templates.

[Django]

#31478: Template.get_exception_info relies on internal state which isn't correct
for sub-templates.
-+--
 Reporter:  Keryn Knight |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham):

 Duplicate of #28935?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cdcefb33a86b7da1835cc4704be08bcf%40djangoproject.com.

Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

[Django]

#17664: {% if %} template tag silences exceptions inconsistently
-+-
 Reporter:  Tai Lee  |Owner:  Robert
 |  Roskam
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12752

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1d6725431ce560557c3425acaf80c984%40djangoproject.com.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 Added a small test here: https://github.com/django/django/pull/12751

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.8ad092fa4891ce7be733bf1b9f134aa1%40djangoproject.com.

Re: [Django] #30372: Django (moderately) High CPU usage at Idle

[Django]

#30372: Django (moderately) High CPU usage at Idle
-+-
 Reporter:  Benjamin Schollnick  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 Hey Andy,

 I have a hunch about where some of this excess load comes from. If you're
 willing it would be very helpful if you could try installing my branch:

 {{{
 pip install https://github.com/orf/django/archive/30372-speedups.zip
 }}}

 Alternatively you could set the `USE_I18N` setting to `False` in your
 project.

 I think it's the code that recurses through the `locale` directories to
 watch for changes to `.mo` files. Django ships with a large number of
 built in translation files that never change, and iterating through the
 several hundred directories might be the cause of some of the slowdown
 you're seeing.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.24fad14355760c833f35acbb98eb8a1b%40djangoproject.com.

Re: [Django] #31479: Add support to reset sequences on SQLite

[Django]

#31479: Add support to reset sequences on SQLite
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #31416: FieldError when migrating field to new model subclass.

[Django]

#31416: FieldError when migrating field to new model subclass.
---+
 Reporter:  Eduard Anghel  |Owner:  Nan Liu
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Adam (Chainz) Johnson):

 Hi @nanliu

 I believe the test for this should be in `test_autodetector.py`. The tests
 there don't create whole migrations. They make assertions on the output
 operations.

 Check out the test I wrote for a similar ticket in
 https://github.com/django/django/pull/12313/files#diff-
 c11e6432df7086eda3dfb9ab8e5b2839 , and those around that. They set up the
 before and after model states, ask the autodetector to find the operations
 through `get_changes()`, then make assertions on the operations.

 The "before" model states describe the state of the models before the
 change, which would be pulled from the migration history - in this case
 where just `Readable` exists. The "after" states describe the state the
 current model state, which would be pulled from the apps' model definitios
 - in this case, `Readable` with no fields and `Book` with the `title`
 field.

 When writing a test, please try use the predefined model states to reduce
 memory usage.

 Hope that helps you write a test. Once there's a failing test it should be
 easier to try find the fix.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.4158597cea85976603fb535a2d68f385%40djangoproject.com.

Re: [Django] #31474: QuerySet.Delete - inconsistent result when zero objects deleted

[Django]

#31474: QuerySet.Delete - inconsistent result when zero objects deleted
-+-
 Reporter:  Adi Gabaie   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  querySet Delete  | Triage Stage:  Accepted
  counter|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * has_patch:  0 => 1


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

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

Re: [Django] #31479: Add support to reset sequences on SQLite

[Django]

#31479: Add support to reset sequences on SQLite
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12748

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6f52ad64873f7e704ffbfd977f02df16%40djangoproject.com.

Re: [Django] #31478: Template.get_exception_info relies on internal state which isn't correct for sub-templates.

[Django]

#31478: Template.get_exception_info relies on internal state which isn't correct
for sub-templates.
-+--
 Reporter:  Keryn Knight |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Keryn Knight):

 Example project is here: https://github.com/kezabelle/django-ticket-31478

 The 2 dependencies are Django and the app with which I encountered the
 problem, which is itself a terrible set of monkeypatches upon the Django
 Template Language. There's probably cleaner ways to demonstrate the issue,
 but this is the quickest one I obviously have at hand. As far as I know
 it's not specifically the monkeypatch at fault, but I could be wrong.

 Steps to hopefully reproduce:
 - clone repo
 - install requirements in root of repo (`pip install -r requirements.txt`)
 - boot runserver.
 - navigate your browser to `/fine` with DEBUG turned on, so the technical
 500 renders. You should hopefully observe that the template's HTML is
 shown, and the error is ''highlighted correctly'' as `{{ force_error }}`
 - navigate to `/problem` to see the error being described in the ticket
 proper. You should hopefully observe that the HTML shown is that of the
 `base.html` template rather than the `subtemplate.html` which **extends**
 `base.html` - as a result, ''the HTML is wrong, there is no line to
 highlight, and it reports the error at line 0''.

 With the proposed possible changes, the error is highlighted correctly on
 `/problem`, the line is reported as line 4 correctly, and the path to the
 template shown is the correct subtemplate rather than the base 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.339c3d8db3f60eac7d908e1d96325b2d%40djangoproject.com.

[Django] #31479: Add support to reset sequences on SQLite

[Django]

#31479: Add support to reset sequences on SQLite
-+-
   Reporter:  Jon|  Owner:  nobody
  Dufresne   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Can use the internal `sqlite_sequence` table:

 https://sqlite.org/fileformat2.html#seqtab

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.976adec8e01714e6270f56fedd12bace%40djangoproject.com.

[Django] #31478: Template.get_exception_info relies on internal state which isn't correct for sub-templates.

[Django]

#31478: Template.get_exception_info relies on internal state which isn't correct
for sub-templates.
---+
   Reporter:  Keryn Knight |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Currently, the method is defined as:
 {{{
 def get_exception_info(self, exception, token):
 }}}
 and internal to it's scope, makes use of the values `self.source` and
 `self.origin.name`

 These 2 variables are not necessarily the data on which the operations
 should apply, at least in some scenarios. I have a demo project while I'll
 attach to hopefully demonstrate this.

 The problem exists on 2.2, 3.0 & master (being 3.1 currently). Whilst I've
 not done an exhaustive sweep of the potential problems, a solution which
 seems to work in my limited test is thus:

 Method signature becomes
 {{{
 def get_exception_info(self, exception, token, origin=None, source=None):
 if source is None:
 source = self.source
 if origin is None:
 origin = self.origin
 }}}
 Why support Nones? Because at the very least I think django-debug-toolbar
 makes use of the method, and it leaves it backwards compatible.

 The callers I'm aware of are
 `django.template.base.Template.compile_nodelist`, which would become:
 {{{
 e.template_debug = self.get_exception_info(e, e.token, self.origin,
 self.source)
 }}}
 though I think that given that is passing in the *same* data, it could
 actually remain unchanged, because the internal state is the same both
 ways.

 ... and `django.template.base.Node.render_annotated`:
 {{{
 e.template_debug = context.render_context.template.get_exception_info(e,
 self.token, context.template.origin, context.template.source)
 }}}
 This one is what I presume is the crux of the problem, because the render
 context's template is not the same as the child template.

 Of course, changing the origin and source might have other knock on
 effects that I've not encountered in my tests, and I haven't tried the
 proposed changes against the test suite 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.e926d32f7e8d8c0286670f3e56dcb08b%40djangoproject.com.

Re: [Django] #31471: update_or_create object returns either an unparsed field (like a str) or datetime for DateTimeField, depending on whether object is saved or not.

[Django]

#31471: update_or_create object returns either an unparsed field (like a str) or
datetime for DateTimeField, depending on whether object is saved or not.
-+-
 Reporter:  Fonville |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  datetime, OneToOne   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 While I haven't investigated the details here, I'm inclined to say that
 behavior probably won't change. See, for example, past tickets like
 #12401.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6cb72abc46331c05cb9cabb7190e4683%40djangoproject.com.

Re: [Django] #31413: migrations.test_loader not isolated on databases that don't support transactions.

[Django]

#31413: migrations.test_loader not isolated on databases that don't support
transactions.
+
 Reporter:  Tim Graham  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Tim Graham):

 There might be other failures to fix beyond the scope of this ticket.
 MyISAM isn't tested on CI.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.99730d3108731c306b07303de42e5594%40djangoproject.com.

Re: [Django] #21429: BaseCommand should use logging instead of custom output wrappers

[Django]

#21429: BaseCommand should use logging instead of custom output wrappers
-+-
 Reporter:  Nical|Owner:  François
 |  Freitag
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  command output   | Triage Stage:  Accepted
  logger |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by François Freitag):

 * owner:  John Kang => François Freitag


Comment:

 It seems this ticket stalled. I am interested in seeing that feature in
 Django, resuming work on it.

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

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

Re: [Django] #31413: migrations.test_loader not isolated on databases that don't support transactions.

[Django]

#31413: migrations.test_loader not isolated on databases that don't support
transactions.
+
 Reporter:  Tim Graham  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  3.0
 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 Sanskar Jaiswal):

 I ran all migrations tests on a non-transactional database (MyISAM), and a
 total of 13 tests failed in `migrations.test_loader`,
 `migrations.test_operations.py`, `migrations.test_executer.py` and
 `migrations.test_commands`. Is this behaviour expected?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.93ac7295bdd02be8bd6fe36964b705dd%40djangoproject.com.