Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  using, database, | Triage Stage:  Accepted
  documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Marco Bonetti):

 Thanks for your feedback. On hindsight it seems pretty obvious that
 `using()` does indeed get inherited by the cloned querysets. Closing.

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

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

[Django] #29485: Testing with Oracle in AWS RDS (oracle managed files)

[Django]

#29485: Testing with Oracle in AWS RDS (oracle managed files)
-+-
   Reporter:  Vackar |  Owner:  nobody
  Afzal  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Testing|Version:  2.0
  framework  |   Keywords:  oracle, testing,
   Severity:  Normal |  OMF, AWS, RDS
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am trying to run y test suite against an oracle server running on amazon
 web services under RDS.

 It fails when executing this statement:
 {{{
 CREATE TABLESPACE NAME_OF_TBS
DATAFILE 'name_of_tbs_dev1.dbf' SIZE 50M
REUSE AUTOEXTEND ON NEXT 25M MAXSIZE 500M
 }}}

 Error message is:
 {{{
 ORA-20900: RDS only supports Oracle Managed Files. Check ddl and remove
 any named identifiers
 ORA-06512: at "RDSADMIN.RDSADMIN", line 211
 ORA-06512: at line 2)
 }}}

 What is the best way to add support for oracle managed files i.e.
  - Additional param in django settings?
  - Catch this exception and generate an OMF compatible SQL statement?

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

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

[Django]

#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 OK, patch looks good.

 I have a small reservation about whether we want yet more API on
 ModelAdmin to add the `not_empty_value_display` option, rather than
 steering users to subclassing `FieldListFilter` themselves, but bar
 that...

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

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

Re: [Django] #29482: simplify KeyTransform to always use the 'nested_operator'

[Django]

#29482: simplify KeyTransform to always use the 'nested_operator'
+--
 Reporter:  David De Sousa  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.0
 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 David De Sousa):

 Replying to [comment:1 Simon Charette]:
 > From my understanding the `->` and `->>` operators are used instead of
 their `#` variant when the key lookup depth is 1 for readability purposes.
 >
 > Is there a reason you can't create your non-nested attribute lookups
 using the `->` and `->>` operators instead? Are you suggesting we favor
 the `#` syntax because a functional index on `data#>'{a,b}'` would be used
 when doing a `data#>'{a}'` lookup?

 No, that won't happen AFAIK
 >
 > I'm asking because changing it at this point is likely to break any
 previously created functional index created using these operators for the
 same reason you are asking them to be changed here. I assume this is
 something that would eventually be fixed in PostgreSQL.

 It would be awesome if PostgreSQL dealt with this, but I asked in the
 #postgres IRC and was told there's no way for the query planner to do
 this, although I got confirmation the `#` and `-` operators are
 equivalent.

 No, the issue is that django uses both operators based on if it's a root
 key or a nested one, I agree a change here would potentially break
 previously created indexes using the `->`  or `-->` operators, so
 developers should take this into consideration when building indexes, it
 should at least be documented, I found out the hard way.

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

Re: [Django] #29433: templatefilter "make_list" should receive a optional split variable

[Django]

#29433: templatefilter "make_list" should receive a optional split variable
-+-
 Reporter:  danilovmy|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  templatefilter,  | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by hehaha):

 * owner:  hehaha => (none)
 * status:  assigned => new


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

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

Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  using, database, | Triage Stage:  Accepted
  documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marco Bonetti):

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


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

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

[Django] #29484: Remove the need to specify SPATIALITE_LIBRARY_PATH with Spatialite 4.2+

[Django]

#29484: Remove the need to specify SPATIALITE_LIBRARY_PATH with Spatialite 4.2+
+
   Reporter:  Claude Paroz  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Currently you need to add `SPATIALITE_LIBRARY_PATH = 'mod_spatialite'` to
 your settings (or `'mod_spatialite.so'` on Ubuntu 18.04). Django could try
 to load those values automatically.

 [https://github.com/django/django/pull/10017 PR]

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

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

Re: [Django] #29478: cached_property decorator doesn't work with mangled method names

[Django]

#29478: cached_property decorator doesn't work with mangled method names
-+
 Reporter:  Thomas Grainger  |Owner:  hehaha
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  2.0
 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 hehaha):

 * status:  new => assigned
 * owner:  nobody => hehaha


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

Re: [Django] #29448: Create management command management command

[Django]

#29448: Create management command management command
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 |  McLaughlin
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Katie McLaughlin):

 Replying to [comment:3 Carlton Gibson]:

 > I hope that's fair.

 Totally fair.

 > Django Extensions

 I really need to investigate this one more. I was told in passing "Oh,
 Django Extensions does that" (in the context of something else), but
 without knowing what Django Extensions *is*, where it sits in the
 ecosystem, and realising it's purpose, I totally accept that this issue is
 outside of scope of core.

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

Re: [Django] #29464: Move collectstatic post processing messages to verbosity 2

[Django]

#29464: Move collectstatic post processing messages to verbosity 2
-+-
 Reporter:  David Szotten|Owner:  Arthur
 Type:   |  Silva
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Arthur Silva):

 Hi @Tim Graham,

 How can I test post_process inside TestCollectionVerbosity class located
 in django/tests/staticfiles_tests/test_management.py ?

 I've tried:


 {{{
 def test_verbosity_1(self):
 stdout = StringIO()
 self.run_collectstatic(verbosity=1, stdout=stdout,
 post_process=True)
 output = stdout.getvalue()
 self.assertIn(self.staticfiles_copied_msg, output)
 self.assertNotIn(self.copying_msg, output)
 self.assertNotIn(self.post_process_msg, output)
 }}}

 where self.post_process_msg is equal to 'Post-process'.

 However I can't make post_process be triggered. So, the test passes even
 message post_process_msg is printed with verbose=1.

 I may be missing some 'storage' initialization.

 Can you give a hint, please?

 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.1448ba72f1e9a00bf51fe6a35a92f979%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29448: Create management command management command

[Django]

#29448: Create management command management command
-+-
 Reporter:  Katie McLaughlin |Owner:  Katie
 |  McLaughlin
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 I feel this one.

 It's not that the instructions are good/correct, it's that "Ooo, I can
 make a management command" leads straight to, "Oh, I have to create a
 folder, and an `__init__.py`, Oh and another folder, Oh and another
 `__init__.py`.

 And then it's, "Oh, hang on, what are the imports?" and "What do I have to
 subclass?" and "What methods do I need to implement?".

 It's a real pain.

 I'm going to say `wontfix` on this though, since [https://django-
 extensions.readthedocs.io/en/latest/command_extensions.html Django
 Extensions already implements a `create_command` command], which sets up
 the folders and puts a command scaffolding in ([https://github.com/django-
 extensions/django-
 
extensions/blob/master/django_extensions/conf/command_template/management/commands/sample.py.tmpl
 that looks like this]).

 That does the job perfectly. I don't think we can improve.

 _Maybe_ pulling it into core, but the whole point of Django Extensions is
 that useful stuff lives there that we haven't (and may or may not pull
 in). As a community we should make sure users know it exists, since it's
 great.

 I hope that's fair. Katie, if you still think, "Yes, this should be in
 core" then please follow up on Django Developers and we can discuss.

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

Re: [Django] #29426: UUID fields display poorly in the admin

[Django]

#29426: UUID fields display poorly in the admin
--+
 Reporter:  Aymeric Augustin  |Owner:  mackong
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Forms |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:  uuid  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

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

Re: [Django] #29428: Add support to admin for expressions like (Lower('myfield'), ) in model Meta.ordering

[Django]

#29428: Add support to admin for expressions like (Lower('myfield'),) in model
Meta.ordering
-+-
 Reporter:  Dutch Stiphout   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  admin ordering   | Triage Stage:  Accepted
  expression AttributeError  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nicolas Noé):

 * status:  assigned => new
 * owner:  Nicolas Noé => (none)


Comment:

 Sorry guys, I"ve been much more busy than expected lately. Deassigning the
 ticket 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.75045e898c8607aae881facbc5ec16f2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  feature test models  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by direx):

 * cc: direx (added)


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

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

Re: [Django] #29482: simplify KeyTransform to always use the 'nested_operator'

[Django]

#29482: simplify KeyTransform to always use the 'nested_operator'
+--
 Reporter:  David De Sousa  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  2.0
 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 David De Sousa):

 Replying to [comment:2 Matthew Schinckel]:
 > Does it need something to do with array elements vs object keys? Or does
 the postgres nested operator already handle that?

 `#>>` is a path operator, so it will work also with array indexes, #>>
 '{2}' would give you the 3rd element of the root array.
 >
 > If you had a top-level (and non-nested) JSON array in a field, you'd
 probably want to stick to a simpler index/operator, I think.

 As I said before I could agree with this, although I'd vouch for
 simplicity in the code, using only the path operator makes the code a lot
 simpler IMHO

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

Re: [Django] #29433: templatefilter "make_list" should receive a optional split variable

[Django]

#29433: templatefilter "make_list" should receive a optional split variable
-+-
 Reporter:  danilovmy|Owner:  hehaha
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  templatefilter,  | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by hehaha):

 * owner:  nobody => hehaha
 * status:  new => assigned


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

Re: [Django] #29297: Exception ignored in: . at 0x111aafe08>

[Django]

#29297: Exception ignored in: . at 0x111aafe08>
-+-
 Reporter:  kingctan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Rubi Mazaki):

 Had the same issue too. I am accessing db through multiple threads (via
 APScheduler) and got the very same "ignored exception" as described above.

 YET, Seems it is a PyCharm debugger issue. I followed the link given
 above: [https://youtrack.jetbrains.com/issue/PY-30036]

 Setting the evironment variable PYDEVD_USE_FRAME_EVAL=NO to the debug
 configuration of pycharm **Fixed It!

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

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

Re: [Django] #28539: REMOTE_USER auth docs (and middleware logging?) should mention that headers with underscores are stripped when using "runserver" command

[Django]

#28539: REMOTE_USER auth docs (and middleware logging?) should mention that 
headers
with underscores are stripped when using "runserver" command
-+-
 Reporter:  jcmcken  |Owner:  Israel
 |  Fermín Montilla
 Type:  New feature  |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 As I commented on [https://github.com/django/django/pull/9960 the PR], the
 `runserver` behavior of stripping underscores is documented in the docs
 for `HttpRequest.META` which is linked in the existing sentence. The
 example of using `curl` seems outside the scope of Django's documentation.

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

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

Re: [Django] #29297: Exception ignored in: . at 0x111aafe08>

[Django]

#29297: Exception ignored in: . at 0x111aafe08>
-+-
 Reporter:  kingctan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Rubi Mazaki):

 * resolution:  needsinfo => 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 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.0489a77a143ecf52ca8f267b37fc8438%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29483: Confirm support for GDAL 2.3

[Django]

#29483: Confirm support for GDAL 2.3
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  2.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 Claude Paroz):

 I just compiled a fresh 2.3 and obtained those 2 failures only:
 {{{
 ==
 FAIL: test_poly_multi (gis_tests.inspectapp.tests.OGRInspectTest)
 --
 Traceback (most recent call last):
   File "/home/claude/checkouts/django-
 git/tests/gis_tests/inspectapp/tests.py", line 91, in test_poly_multi
 self.assertIn('geom = models.MultiLineStringField(srid=-1)',
 model_def)
 AssertionError: 'geom = models.MultiLineStringField(srid=-1)' not found in
 '# This is an auto-generated Django model module created by
 ogrinspect.\nfrom django.contrib.gis.db import models\n\n\nclass
 MyModel(models.Model):\nlaenge = models.FloatField()\nbreite =
 models.FloatField()\nnummer = models.BigIntegerField()\ngeom =
 models.MultiLineStringField(srid=31253)'

 ==
 FAIL: test05_geometries (gis_tests.gdal_tests.test_ds.DataSourceTest)
 Testing Geometries from Data Source Features.
 --
 Traceback (most recent call last):
   File "/home/claude/checkouts/django-
 git/tests/gis_tests/gdal_tests/test_ds.py", line 230, in test05_geometries
 self.assertIsNotNone(re.match(wgs_84_wkt_regex, g.srs.wkt))
 AssertionError: unexpectedly None
 }}}

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

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

Re: [Django] #29483: Confirm support for GDAL 2.3

[Django]

#29483: Confirm support for GDAL 2.3
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  2.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 Claude Paroz):

 This [https://github.com/django/django/pull/10037 PR] is solving the WGS
 84 regex. I have no idea for the other failure, how GDAL can find a 31253
 srid.
 Note also that we should drop official support for GDAL 1.9 and 1.10 at
 least.

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

Re: [Django] #29458: Documentation incorrectly says Model._meta.get_field() uses related_name instead of related_query_name (was: get_field uses related_query_name instead of related_name)

[Django]

#29458: Documentation incorrectly says Model._meta.get_field() uses related_name
instead of related_query_name
---+
 Reporter:  Tomasz Knapik  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 I haven't investigated in detail but I imagine the documentation should be
 updated.

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

Re: [Django] #29470: Add output to makemigrations and migrate commands with --noinput

[Django]

#29470: Add output to makemigrations and migrate commands with --noinput
--+--
 Reporter:  Kurt Wheeler  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Migrations|  Version:  1.11
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

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


Comment:

 This looks like a similar request as #29026, even if the proposed
 implementation is a bit different.

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

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

Re: [Django] #29026: Make makemigrations scriptable / script-friendly

[Django]

#29026: Make makemigrations scriptable / script-friendly
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  makemigrations,scripting,stderr,stdout|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I closed #29470 as a duplicate.

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

Re: [Django] #29480: mysql constraints are sometimes retrieved out of the order that they are defined in

[Django]

#29480: mysql constraints are sometimes retrieved out of the order that they are
defined in
-+-
 Reporter:  Thomas Grainger  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.0
  (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 Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Database layer (models, ORM)
 * easy:  1 => 0
 * 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 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.8c2ab136e6f744013c9f99ff9935bf98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29297: Exception ignored in: . at 0x111aafe08>

[Django]

#29297: Exception ignored in: . at 0x111aafe08>
-+-
 Reporter:  kingctan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * resolution:  needsinfo => invalid


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

Re: [Django] #29440: Document that RelatedManager.set() doesn't accept bulk keyword argument for many-to-many relations

[Django]

#29440: Document that RelatedManager.set() doesn't accept bulk keyword argument 
for
many-to-many relations
-+-
 Reporter:  Jeremy Lainé |Owner:  Jeremy
 |  Lainé
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"741792961815cf4a95c5ce8ab590dfc7700c6153" 74179296]:
 {{{
 #!CommitTicketReference repository=""
 revision="741792961815cf4a95c5ce8ab590dfc7700c6153"
 Fixed #29440 -- Doc'd where the bulk argument applies in RelatedManager.
 }}}

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

Re: [Django] #29440: Document that RelatedManager.set() doesn't accept bulk keyword argument for many-to-many relations

[Django]

#29440: Document that RelatedManager.set() doesn't accept bulk keyword argument 
for
many-to-many relations
-+-
 Reporter:  Jeremy Lainé |Owner:  Jeremy
 |  Lainé
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"36c35aba094ac0b27620328bd48099bc971aca20" 36c35aba]:
 {{{
 #!CommitTicketReference repository=""
 revision="36c35aba094ac0b27620328bd48099bc971aca20"
 [2.1.x] Fixed #29440 -- Doc'd where the bulk argument applies in
 RelatedManager.

 Backport of 741792961815cf4a95c5ce8ab590dfc7700c6153 from master
 }}}

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

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

Re: [Django] #29484: Remove the need to specify SPATIALITE_LIBRARY_PATH with Spatialite 4.2+

[Django]

#29484: Remove the need to specify SPATIALITE_LIBRARY_PATH with Spatialite 4.2+
-+-
 Reporter:  Claude Paroz |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #29466: Textual "to" parameter of ForeignKey fails to resolve if placed in abstract model

[Django]

#29466: Textual "to" parameter of ForeignKey fails to resolve if placed in 
abstract
model
-+-
 Reporter:  Vitalik Verhovodov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Reproduced at 741792961815cf4a95c5ce8ab590dfc7700c6153.

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

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