Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  Alberto
 |  Misail
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 Hello Alberto!

 Thank you for your report but unfortunately Django doesn't ship with a
 MSSQL backend.

 Since it's unlikely any of the default backends (SQLite, PostgreSQL,
 MySQL, Oracle) exhibit such behavior you should report this issue to the
 third-party app providing the database backend you are using instead.

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

Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  Alberto
 |  Misail
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alberto Misail):

 * Attachment "tests.py" added.

 Tests file

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

Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  Alberto
 |  Misail
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alberto Misail):

 * Attachment "tests.py" added.

 Tests file

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

Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  Alberto
 |  Misail
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alberto Misail):

 * status:  new => assigned
 * owner:  nobody => Alberto Misail


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

Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alberto Misail):

 * Attachment "models.py" added.

 Models file

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

Re: [Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
 Reporter:  Alberto Misail   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  TextField| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alberto Misail):

 * Attachment "tests.py" added.

 Tests file

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

[Django] #29194: Saving entry into db fails when value of a textfield type parameter is too big (more than 6000 char)

2018-03-06 Thread Django 
#29194: Saving entry into db fails when value of a textfield type parameter is 
too
big (more than 6000 char)
-+-
   Reporter:  Alberto|  Owner:  nobody
  Misail |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  TextField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When a model has a textfield type parameter, the value of this parameter
 should be a string of any size.
 Nonetheless, when trying to insert a new entry where this string is longer
 than 6000 chars it fails throwing an invalid precision value.
 Note that when trying with small sizes it works
 I am using a MS SQL database, Django 1.11.9 and Python 3.5.2
 Find attached the models file and the test cases that show the 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/051.a4eee8891382ad28ea347650e8006f87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29188: ContentFile.size remains constant after initializing

2018-03-06 Thread Django 
#29188: ContentFile.size remains constant after initializing
-+-
 Reporter:  Maksim Iakovlev  |Owner:  Alex
 |  Stovbur
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  1.11
  uploads/storage|
 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 Alex Stovbur):

 * cc: Alex Stovbur (added)
 * owner:  nobody => Alex Stovbur
 * 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.fc576344fda83505d63aed62111fa974%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28943: Avoid the need to call get_context_data() in TemplateView subclasses

2018-03-06 Thread Django 
#28943: Avoid the need to call get_context_data() in TemplateView subclasses
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Generic views|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 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 James Pic):

 >  Unless I missed something, super().get() will call the TemplateView
 implementation, even if you override get() in a subclass.

 That's True unless YourFooDetailView inherits from YourProjectDetailView
 which would inherit from django.views.generic.DetailView.

 When you work as a Django user, you often want to add a project-specific
 layer between your actual user facing views and django views, ie. to
 refactor common features you have in all your
 {List,Detail,Update,Create,Form,Object,Model}View classes accross the
 project's app.

 And anyway, I think get_context_data() deserves to be removed from
 Django's public API, this is made to support legacy templates, new
 templates just use {{ view.object }} than {{ object }} because then they
 make @object a memoized property which they can always use in
 {dispatch,get,post,delete,options} methods instead of thinking they're
 paid by the quantity of lines of code and take pride in overriding and
 decorating get_context_data() for no reason thanks to the visionary who
 made view=self a default in CBV.

 Maybe what I'm saying doesn't make any sense to anybody than myself lol
 but at least you can point-godwin me because i don't consider the
 resolution of this ticket worksforme, but don't take it personnaly, you
 know i still admire you from the deepest of my heart Tim <3

 With LOVE
 ∞

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

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

2018-03-06 Thread Django 
#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  2.1  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Christoph Schwarzenberg):

 Maybe it is enough to check the supplied password.

 I've modified the code from shangdahao accordingly:
 https://stackoverflow.com/a/49138231/9453030

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

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

Re: [Django] #28645: AuthenticationForm's inactive user error isn't raised when using ModelBackend

2018-03-06 Thread Django 
#28645: AuthenticationForm's inactive user error isn't raised when using
ModelBackend
-+-
 Reporter:  Guilherme Junqueira  |Owner:
 |  shangdahao
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  2.1  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Christoph Schwarzenberg):

 * cc: Christoph Schwarzenberg (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/068.95c31a5017e938e111303a95462983b7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29192: Docs on abstract base models say you can't override abstract fields

2018-03-06 Thread Django 
#29192: Docs on abstract base models say you can't override abstract fields
+--
 Reporter:  Marten Kenbeek  |Owner:  klee05
 Type:  Bug |   Status:  assigned
Component:  Documentation   |  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
+--
Changes (by klee05):

 * owner:  nobody => klee05
 * 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/062.d818a5eebe3188ea810b50db480d9b7f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29193: Altering a field with a unique constraint drops and rebuilds FKs to other fields in the table

2018-03-06 Thread Django 
#29193: Altering a field with a unique constraint drops and rebuilds FKs to 
other
fields in the table
-+
   Reporter:  Jeremy Bowman  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Migrations |Version:  1.11
   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  |
-+
 In #28305, a bug was fixed that prevented a MySQL field with a unique
 constraint from being altered if there was a foreign key constraint on it.
 However, the fix itself seems to have a more subtle bug in it: instead of
 dropping and recreating just foreign keys affecting that particular field,
 it does so for all foreign key constraints on any field in that table.
 This still yields a valid result, but for large tables with many incoming
 FK constraints this can dramatically increase the duration of the
 migration.

 In particular, migration 0008 from django.contrib.auth (which changes the
 length of the username, a field with a unique constraint) now causes all
 foreign keys to the user ID to be dropped and later recreated throughout
 the database.  I'm working with a MySQL database where this increases the
 duration of the migration from 10-20 minutes to nearly 48 hours, during
 most of which writes are blocked on at least one of the tables for which
 the indexes need to be recreated. Thankfully, we caught it during load
 testing with a production-sized database before attempting a production
 deployment.  This particular manifestation of the problem only hits
 installations that were populated with data using a pre-1.10 version of
 Django but are attempting to go straight to 1.11 or above (which I suspect
 is actually fairly common given that 1.8 and 1.11 are LTS versions, and
 1.10 is no longer being supported).

 The problem seems to be in the usage of `_related_non_m2m_objects` to
 enumerate the foreign key constraints; this function returns all relations
 involving the table of the field provided, not just that specific field.
 I discovered the bug in 1.11, but it still seems to be present in 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/051.343cd7cb081033db1fd04813760dd5bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29191: Move the model name to the beginning of the page title for admin add/change/delete pages (was: Admin page title)

2018-03-06 Thread Django 
#29191: Move the model name to the beginning of the page title for admin
add/change/delete pages
-+-
 Reporter:  Dmitrij Strelnikov   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 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:   => wontfix


Comment:

 Thanks for the proposal, but I don't see much advantage to the change. The
 wording is less natural and that ordering could have a similar problem in
 the case of opening add/change/delete pages for the same model.

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

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

[Django] #29192: Docs on abstract base models say you can't override abstract fields

2018-03-06 Thread Django 
#29192: Docs on abstract base models say you can't override abstract fields
--+
   Reporter:  Marten Kenbeek  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Documentation   |Version:  2.0
   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   |
--+
 In the docs on [https://docs.djangoproject.com/en/2.0/topics/db/models
 /#abstract-base-classes abstract base models] it says:

 > It is an error to have fields in the abstract base class with the same
 name as those in the child (and Django will raise an exception).

 This is incorrect since #24305 was 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/047.bd0608817e029429929c9b36522cd2d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29191: Admin page title

2018-03-06 Thread Django 
#29191: Admin page title
+
   Reporter:  Dmitrij Strelnikov|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  2.0
   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 |
+
 Hi guys, I do have some admin improvements proposal.
 The page title is generated automatically by django with default model
 names but I found big issue with current approach.
 Title on change/add/remove pages contains

 {{{
 {% blocktrans %}Change selected {{ model }}{% endblocktrans %}
 {% blocktrans %}Add another {{ model }}{% endblocktrans %}
 {% blocktrans %}Delete selected {{ model }}{% endblocktrans %}
 }}}

 When you have open few more tabs, it's actually show only 'Change
 selecte...' next to favico.
 So with bunch of tabs you have absolutely no idea what tab is representing
 what page without manually activating particular tab.

 What do you think is it possible to add the model name at the beginning of
 the title?
 {{{
 {% blocktrans %}{{ model }} change selected{% endblocktrans %}
 }}}

 etc..I know it should be translated for all languages.
 I'm able to create PR if you agree with the proposal.

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

Re: [Django] #29170: Oracle - Unable to add triggers in migrations, semicolon removed.

2018-03-06 Thread Django 
#29170: Oracle - Unable to add triggers in migrations, semicolon removed.
-+-
 Reporter:  Danny Willems|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  oracle trigger   | Triage Stage:
  database   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 I cannot reproduce this issue. Please reopen this ticket if you can
 provide a falling test.

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

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

Re: [Django] #29190: timezone.is_aware() raises unhandled exception when receiving datetime.date object as argument

2018-03-06 Thread Django 
#29190: timezone.is_aware() raises unhandled exception when receiving 
datetime.date
object as argument
-+-
 Reporter:  Dariem Pérez |Owner:  nobody
  Herrera|
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  timezone date| Triage Stage:
  datetime   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 
[https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.timezone.is_aware
 The documentation] says, "This function assumes that value is a datetime."
 Do you have a compelling use case to add support for  `datetime.date`?

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

[Django] #29190: timezone.is_aware() raises unhandled exception when receiving datetime.date object as argument

2018-03-06 Thread Django 
#29190: timezone.is_aware() raises unhandled exception when receiving 
datetime.date
object as argument
-+-
   Reporter:  Dariem |  Owner:  nobody
  Pérez Herrera  |
   Type:  Bug| Status:  new
  Component:  Utilities  |Version:  1.11
   Severity:  Normal |   Keywords:  timezone date
   Triage Stage: |  datetime
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The exception in question that it raises is `AttributeError:
 'datetime.date' object has no attribute 'utcoffset'`

 How to reproduce:

 {{{#!python
 >>> from django.conf import settings
 >>> settings.configure()
 >>> from django.utils import timezone
 >>> from datetime import date
 >>> d = date(year=2018, month=3, day=30)
 >>> timezone.is_aware(d)
 }}}

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

Re: [Django] #25367: Allow expressions in .filter() calls

2018-03-06 Thread Django 
#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Matthew
 Type:   |  Schinckel
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Smeaton):

 * cc: josh.smeaton@… (added)
 * stage:  Accepted => Ready for checkin


Comment:

 Supporting boolean expressions is enough for the framework. It will be
 possible for 3rd party libs to support more fluent syntaxes by converting
 algebraic expressions into database expressions, similar to how combinable
 works. Whether or not anyone attempts to do that is neither here nor
 there.

 I think this is a really good change. Having to annotate to filter is not
 just cumbersome, but as you've shown also a large performance hit.

 The docs might need a little bit of work, but I think the code and tests
 are fine.

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

Re: [Django] #29120: Document that the admin autocomplete requires the change permission of the related model

2018-03-06 Thread Django 
#29120: Document that the admin autocomplete requires the change permission of 
the
related model
-+-
 Reporter:  Rodrigo Pinheiro |Owner:  Johannes
  Marques de Araújo  |  Hoppe
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  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 Johannes Hoppe):

 Ok, huh, what do you think? I myself thought of the autocomplete field as
 a drop in replacement. Having to give users access to the related model,
 just to display a select field, seems unintuitive.

 Good example would be a foreign key to a user. You don't want anyone but
 superusers to have access to the user model, but you would have to in this
 case.

 A case for the change permission would be unintended data leakage. The
 search_fields could expose more information that the string representation
 does.

 So it's limitation vs risk. Usually I would be prefer to reduce risk, but
 I find it very slim. I would find it more disturbing if people would hand
 out change permissions without a real reason.

 Should I send forward this topic to the mailing list?

 Best
 -Joe

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

Re: [Django] #22449: Colorize output of test results

2018-03-06 Thread Django 
#22449: Colorize output of test results
-+-
 Reporter:  Jake Rothenbuhler|Owner:  Yuri
 |  Shikanov
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 Tim didn't say any implementation wouldn't be merged. He said the current
 implementation doesn't look suitable, and that `unittest` //might// not
 allow an elegant implementation. I agree. Personally, though, I do think
 there is lots of room for a more elegant approach and that the decision
 should be based on the particular patch (and its maintainability, etc).
 It's probably better for implementation issues to be discussed on the PR
 rather than here though.

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

Re: [Django] #22449: Colorize output of test results

2018-03-06 Thread Django 
#22449: Colorize output of test results
-+-
 Reporter:  Jake Rothenbuhler|Owner:  Yuri
 |  Shikanov
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Yuri Shikanov):

 Actually, I agree that proposed implementation has issues. I asked whether
 I should try to refine implementation. As I understand, any implementation
 wouldn't be merged, because unittest doesn't let to create a much more
 elegant implementation.

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