Re: [Django] #30435: __iexact not working inside validator function. (was: __iexact not working inside validator function)

[Django]

#30435: __iexact not working inside validator function.
-+-
 Reporter:  Diego Arturo |Owner:  nobody
  Hernandez Fuentes  |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 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 felixxm):

 * status:  new => closed
 * resolution:   => worksforme
 * version:  2.1 => master
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 First of all please don't shout. Secondly `__iexact` works properly, an
 issue is in your own code. Tip from Ryan Govostes looks reasonable, but
 your code will not work properly on update. You should take into account
 instance etc. Nevertheless it is support issue so please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

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

Re: [Django] #30435: __iexact NOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!!

[Django]

#30435: __iexact NOT WORKING. URGENT!!!
-+-
 Reporter:  Diego Arturo |Owner:  nobody
  Hernandez Fuentes  |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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 Ryan Govostes):

 You are raising your ValidationError inside a `try ... catch` block which
 catches the exception and then does nothing with it. This will prevent the
 ValidationError from escaping your validator.

 Does this work?

 {{{
 def validate_name(self, value):
 if not value:
 raise serializers.ValidationError('Proporciona un valor, por
 favor.')

 exist_name = FundingSource.objects.filter(name__iexact=value)
 if len(exist_name) > 0:
 raise serializers.ValidationError('Este nombre ya fue usado,
 por favor proporciona otro valor.')
 }}}

 Please keep bug report titles simple.

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

Re: [Django] #30435: __iexact not working inside validator function (was: __iexact NOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!!)

[Django]

#30435: __iexact not working inside validator function
-+-
 Reporter:  Diego Arturo |Owner:  nobody
  Hernandez Fuentes  |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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
-+-

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

Re: [Django] #30434: DurationField silently drops negative sign

[Django]

#30434: DurationField silently drops negative sign
-+-
 Reporter:  Ryan Govostes|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 Ryan Govostes):

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


Comment:

 I think this is a duplicate of #30141 which is fixed
 (https://github.com/django/django/pull/10999) but doesn't seem to be in
 the 2.2 branch yet.

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

Re: [Django] #30435: __iexactNOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!! (was: __icontains NOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!!)

[Django]

#30435: __iexactNOT WORKING. URGENT!!!
-+-
 Reporter:  Diego Arturo |Owner:  nobody
  Hernandez Fuentes  |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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
-+-

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

Re: [Django] #30435: __iexact NOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!! (was: __iexactNOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!!)

[Django]

#30435: __iexact NOT WORKING. URGENT!!!
-+-
 Reporter:  Diego Arturo |Owner:  nobody
  Hernandez Fuentes  |
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  2.1
 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
-+-

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

[Django] #30435: __icontains NOT WORKING. URGENT!!!!!!!!!!!!!!!!!!!!!!!

[Django]

#30435: __icontains NOT WORKING. URGENT!!!
-+-
   Reporter:  Diego  |  Owner:  nobody
  Arturo Hernandez Fuentes   |
   Type:  Bug| Status:  new
  Component: |Version:  2.1
  Uncategorized  |
   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  |
-+-
 I have my query into validation to find if exist a duplicate name in my
 model


 {{{
 def validate_name(self, value):
 if not value:
 raise serializers.ValidationError('Proporciona un valor, por
 favor.')

 try:
 exist_name = FundingSource.objects.filter(name__iexact=value)
 # here is the error __icontains is NOT WORKING
 if len(exist_name) > 0:
 raise serializers.ValidationError('Este nombre ya fue
 usado, por favor proporciona otro valor.')  # I need display this message
 in my console to be sure that exists a duplicate
 except Exception as e:
 pass
 else:
 return value
 }}}

 I have in my model

 Funding 1
 Funding 2
 Funding 3
 Funding 4

 Next, I tried to type `funding 1` to disallow me to create that name, but,
 the queryset display me

 

 Then, create new one item in my table.

 Funding 1
 Funding 2
 Funding 3
 Funding 4
 funding 1

 So this is wrong, your __iexact is bad,

 so I need that Django developer team resolve this, now.

 It's urgent, please. What is the best way to develop __iexact or
 __icontains.

 Thanks


 My django version is 2.1.5
 Django rest framework version = 3.9.0

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

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

Re: [Django] #30434: DurationField silently drops negative sign (was: DurationField silently)

[Django]

#30434: DurationField silently drops negative sign
-+-
 Reporter:  Ryan Govostes|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

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

[Django] #30434: DurationField silently

[Django]

#30434: DurationField silently
-+-
   Reporter:  Ryan   |  Owner:  nobody
  Govostes   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  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  |
-+-
 When a negative value, such as `-00:00:05` is written to a DurationField
 via the admin interface, the value is silently converted to `00:00:05`,
 dropping the negative.

 There is no note in the documentation that this would be expected, and
 indeed it seems that #27699 was intended to support negative values for
 DurationFields on SQLite.

 I've tried with both SQLite and PostgreSQL database backends.

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

Re: [Django] #30433: Authentication system is not working with Google Chrome for django 2.1 and 2.2.1

[Django]

#30433: Authentication system is not working with Google Chrome for django 2.1 
and
2.2.1
-+--
 Reporter:  Anurag Gundappa  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  login, CSRF  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Anurag Gundappa):

 * stage:  Accepted => Unreviewed


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

Re: [Django] #30433: Authentication system is not working with Google Chrome for django 2.1 and 2.2.1

[Django]

#30433: Authentication system is not working with Google Chrome for django 2.1 
and
2.2.1
-+
 Reporter:  Anurag Gundappa  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  login, CSRF  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Anurag Gundappa):

 * stage:  Unreviewed => Accepted


Old description:

> I am using django 2.2.1 for my  personal project . It is observed that
> django admin and custom user login works fine with Firefox  but when
> tried to login with same URL on Google Chrome version 74, that doesn't
> works and throws CSRF token error. I  experienced this  issue on Windows
> 10 and Ubuntu 19.04. I could not even sign up for djangoproject  with
> Google chrome.  I have hosted same project on heroku and pythonanywhere
> but still the login behaviour was same. Django 2.1 and  2.2.1 are only
> allowing user login from Firefox and not with Chrome. I double checked my
> Login views  but there is no problem  with my views . TO verify this I
> created new project  with django 2.0 and user login is working as
> expected with FIrefox and Chrome  both. At first I thought login only
> working with default browser  so I tried setting Chrome as my default
> browser but no luck

New description:

 I am using django 2.2.1 for my  personal project . It is observed that
 django admin and custom user login works fine with Firefox  but when tried
 to login with same URL on Google Chrome version 74, that doesn't works and
 throws CSRF token error. I  experienced this  issue on Windows  10 and
 Ubuntu 19.04. I could not even sign up for djangoproject  with Google
 chrome.

 I have hosted same project on heroku and pythonanywhere but still the
 login behaviour was same. Django 2.1 and  2.2.1 are only allowing user
 login from Firefox and not with Chrome. I double checked my Login views
 but there is no problem  with my views . TO verify this I created new
 project  with django 2.0 and user login is working as expected with
 FIrefox and Chrome  both. At first I thought login only working with
 default browser  so I tried setting Chrome as my default browser but no
 luck.

 On Windows 10 I could only login to my project with Microsoft Edge but not
 with Chrome.

--

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

Re: [Django] #30433: Authentication system is not working with Google Chrome for django 2.1 and 2.2.1

[Django]

#30433: Authentication system is not working with Google Chrome for django 2.1 
and
2.2.1
-+-
 Reporter:  Anurag Anurag|Owner:  nobody
  GundappaGundappa   |
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  login, CSRF  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anurag Anurag GundappaGundappa):

 * Attachment "django bug2.png" added.

 Login failure on chrome for my project

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

Re: [Django] #30431: Migration hangs on non default database.

[Django]

#30431: Migration hangs on non default database.
-+-
 Reporter:  mandm|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, uuid,|  worksforme
  uuidfield, database router,| Triage Stage:
  multiple database  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mandm):

 Thank you @felixxm for the suggestions. A quick checks shows that
 `schema_editor.connection.alias` does fix the problem, but this solution
 only works in conjunction with routers i.e. unless I use `allow_migrate`,
 an accidental migration will affect the default database. I'll try the
 support channels to see if there's a way to use the non-default database
 directly in a migration without resorting to routers.

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

Re: [Django] #30433: Authentication system is not working with Google Chrome for django 2.1 and 2.2.1

[Django]

#30433: Authentication system is not working with Google Chrome for django 2.1 
and
2.2.1
-+-
 Reporter:  Anurag Anurag|Owner:  nobody
  GundappaGundappa   |
 Type:  Bug  |   Status:  new
Component:  CSRF |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  login, CSRF  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anurag Anurag GundappaGundappa):

 * Attachment "django bug.png" added.

 The screenshot showing sign up error on djangoproject  with Chrome

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

[Django] #30433: Authentication system is not working with Google Chrome for django 2.1 and 2.2.1

[Django]

#30433: Authentication system is not working with Google Chrome for django 2.1 
and
2.2.1
-+-
   Reporter:  Anurag |  Owner:  nobody
  Anurag GundappaGundappa|
   Type:  Bug| Status:  new
  Component:  CSRF   |Version:  2.2
   Severity:  Release|   Keywords:  login, CSRF
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am using django 2.2.1 for my  personal project . It is observed that
 django admin and custom user login works fine with Firefox  but when tried
 to login with same URL on Google Chrome version 74, that doesn't works and
 throws CSRF token error. I  experienced this  issue on Windows  10 and
 Ubuntu 19.04. I could not even sign up for djangoproject  with Google
 chrome.  I have hosted same project on heroku and pythonanywhere but still
 the login behaviour was same. Django 2.1 and  2.2.1 are only allowing user
 login from Firefox and not with Chrome. I double checked my Login views
 but there is no problem  with my views . TO verify this I created new
 project  with django 2.0 and user login is working as expected with
 FIrefox and Chrome  both. At first I thought login only working with
 default browser  so I tried setting Chrome as my default browser but no
 luck

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

Re: [Django] #30432: Django development server shutdown on error. (was: Django development server shutdown on error)

[Django]

#30432: Django development server shutdown on error.
-+-
 Reporter:  User632716   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Utilities|  Version:  2.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  dev-server   | Triage Stage:
  devserver  |  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:   => duplicate
 * component:  Uncategorized => Utilities


Comment:

 This bug has been fixed in Django `2.2.1`, see
 [https://docs.djangoproject.com/en/2.2/releases/2.2.1/ release notes]:

 > Fixed a regression in Django 2.2 that caused a crash of runserver when
 URLConf modules raised exceptions (#30323).

 Duplicate of #30323.

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

Re: [Django] #30432: Django development server shutdown on error

[Django]

#30432: Django development server shutdown on error
-+-
 Reporter:  User632716   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  dev-server   | Triage Stage:
  devserver  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by User632716:

Old description:

> As in my question on SO
> [here](https://stackoverflow.com/questions/55953263/django-development-
> server-shutdown-on-error) I am running a dev server on localhost to test
> a django app. About a week ago the dev server started exiting on error-
> which is not ideal.
>
> To give you an instance, imagine I want to create a new view, I make my
> template, then I add the following in urls:
>

>   urlpatterns = [
> ...
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
>   ]
>
> I haven't yet created the ForgottenPassword class based view yet, so
> rightly the server throws the error:
>
>   File "/code/accounts/urls.py", line 19, in 
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
>   NameError: name 'ForgottenPassword' is not defined
>
> The server then quits however. This is not the desired behavior. I expect
> the server to remain in an error state until i fix the error (this
> happened up to about a week ago).  It was around the same time that we
> upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

New description:

 As in my question on SO
 [here](https://stackoverflow.com/questions/55953263/django-development-
 server-shutdown-on-error) I am running a dev server on localhost to test a
 django app. About a week ago the dev server started exiting on error-
 which is not ideal.

 To give you an instance, imagine I want to create a new view, I make my
 template, then I add the following in urls:


   urlpatterns = [...,path('forgotten-password',
 ForgottenPassword.as_view(), name='forgotten_password'),...]

 I haven't yet created the ForgottenPassword class based view yet, so
 rightly the server throws the error:

   File "/code/accounts/urls.py", line 19, in 
   path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
   NameError: name 'ForgottenPassword' is not defined

 The server then quits however. This is not the desired behavior. I expect
 the server to remain in an error state until i fix the error (this
 happened up to about a week ago).  It was around the same time that we
 upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

 * Having downgraded to 2.1 we no longer have this problem, it must be to
 do with the update

--

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

Re: [Django] #30432: Django development server shutdown on error

[Django]

#30432: Django development server shutdown on error
-+-
 Reporter:  User632716   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  dev-server   | Triage Stage:
  devserver  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by User632716:

Old description:

> As in my question on SO
> [here](https://stackoverflow.com/questions/55953263/django-development-
> server-shutdown-on-error) I am running a dev server on localhost to test
> a django app. About a week ago the dev server started exiting on error-
> which is not ideal.
>
> To give you an instance, imagine I want to create a new view, I make my
> template, then I add the following in urls:
>

> urlpatterns = [
> ...
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
> ]
>
> I haven't yet created the ForgottenPassword class based view yet, so
> rightly the server throws the error:
>
> File "/code/accounts/urls.py", line 19, in 
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
> NameError: name 'ForgottenPassword' is not defined
>
> The server then quits however. This is not the desired behavior. I expect
> the server to remain in an error state until i fix the error (this
> happened up to about a week ago).  It was around the same time that we
> upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

New description:

 As in my question on SO
 [here](https://stackoverflow.com/questions/55953263/django-development-
 server-shutdown-on-error) I am running a dev server on localhost to test a
 django app. About a week ago the dev server started exiting on error-
 which is not ideal.

 To give you an instance, imagine I want to create a new view, I make my
 template, then I add the following in urls:


   urlpatterns = [
 ...
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
   ]

 I haven't yet created the ForgottenPassword class based view yet, so
 rightly the server throws the error:

   File "/code/accounts/urls.py", line 19, in 
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
   NameError: name 'ForgottenPassword' is not defined

 The server then quits however. This is not the desired behavior. I expect
 the server to remain in an error state until i fix the error (this
 happened up to about a week ago).  It was around the same time that we
 upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

--

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

Re: [Django] #30432: Django development server shutdown on error

[Django]

#30432: Django development server shutdown on error
-+-
 Reporter:  User632716   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  dev-server   | Triage Stage:
  devserver  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by User632716:

Old description:

> As in my question on SO
> [here](https://stackoverflow.com/questions/55953263/django-development-
> server-shutdown-on-error) I am running a dev server on localhost to test
> a django app. About a week ago the dev server started exiting on error-
> which is not ideal.
>
> To give you an instance, imagine I want to create a new view, I make my
> template, then I add the following in urls:
>
> ```python
> urlpatterns = [
> ...
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
> ]
> ```
>
> I haven't yet created the ForgottenPassword class based view yet, so
> rightly the server throws the error:
>
> ```python
> File "/code/accounts/urls.py", line 19, in 
> path('forgotten-password', ForgottenPassword.as_view(),
> name='forgotten_password'),
> NameError: name 'ForgottenPassword' is not defined
> ```
> The server then quits however. This is not the desired behavior. I expect
> the server to remain in an error state until i fix the error (this
> happened up to about a week ago).  It was around the same time that we
> upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

New description:

 As in my question on SO
 [here](https://stackoverflow.com/questions/55953263/django-development-
 server-shutdown-on-error) I am running a dev server on localhost to test a
 django app. About a week ago the dev server started exiting on error-
 which is not ideal.

 To give you an instance, imagine I want to create a new view, I make my
 template, then I add the following in urls:


 urlpatterns = [
 ...
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
 ]

 I haven't yet created the ForgottenPassword class based view yet, so
 rightly the server throws the error:

 File "/code/accounts/urls.py", line 19, in 
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
 NameError: name 'ForgottenPassword' is not defined

 The server then quits however. This is not the desired behavior. I expect
 the server to remain in an error state until i fix the error (this
 happened up to about a week ago).  It was around the same time that we
 upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

--

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

[Django] #30432: Django development server shutdown on error

[Django]

#30432: Django development server shutdown on error
-+-
   Reporter: |  Owner:  nobody
  User632716 |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.2
  Uncategorized  |   Keywords:  dev-server
   Severity:  Normal |  devserver
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 As in my question on SO
 [here](https://stackoverflow.com/questions/55953263/django-development-
 server-shutdown-on-error) I am running a dev server on localhost to test a
 django app. About a week ago the dev server started exiting on error-
 which is not ideal.

 To give you an instance, imagine I want to create a new view, I make my
 template, then I add the following in urls:

 ```python
 urlpatterns = [
 ...
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
 ]
 ```

 I haven't yet created the ForgottenPassword class based view yet, so
 rightly the server throws the error:

 ```python
 File "/code/accounts/urls.py", line 19, in 
 path('forgotten-password', ForgottenPassword.as_view(),
 name='forgotten_password'),
 NameError: name 'ForgottenPassword' is not defined
 ```
 The server then quits however. This is not the desired behavior. I expect
 the server to remain in an error state until i fix the error (this
 happened up to about a week ago).  It was around the same time that we
 upgraded from django 2.1 to 2.2, is this a desired behaviour in 2.2?

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

Re: [Django] #30431: Migration hangs on non default database. (was: Migration hangs on non default database)

[Django]

#30431: Migration hangs on non default database.
-+-
 Reporter:  mandm|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, uuid,|  worksforme
  uuidfield, database router,| Triage Stage:
  multiple 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
 * version:  1.11 => master
 * resolution:   => worksforme


Comment:

 Thanks for the report, but described case works for me.

 First of all you should use `schema_editor.connection.alias` in
 `gen_uuid()` to fix it for multiple databases (see
 [https://docs.djangoproject.com/en/stable/ref/migration-
 operations/#runpython RunPython]), .e.g.
 {{{#!python
 def gen_uuid(apps, schema_editor):
 UserModel = apps.get_model('myapp', 'customuser')
 db_alias = schema_editor.connection.alias
 for row in UserModel.objects.using(db_alias).all():
 row.uniq_id = uuid.uuid4()
 row.save(update_fields=['uniq_id'])
 }}}

 Secondly in mentioned documentation we have three separate migrations not
 one. It depends on database but in e.g. PostgreSQL you will not be able to
 alter column and update date in a single transaction. My advice is to
 split migration files and use `schema_editor.connection.alias`.

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] if you need furher help.

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

Re: [Django] #29692: Incorrect removal of order_by clause created as multiline RawSQL

[Django]

#29692: Incorrect removal of order_by clause created as multiline RawSQL
-+-
 Reporter:  Marcin Nowak |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * version:  1.11 => 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/065.e612c1fa1512f066d21feaf228ffb4cd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30431: Migration hangs on non default database

[Django]

#30431: Migration hangs on non default database
-+-
 Reporter:  mandm|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, uuid,| Triage Stage:
  uuidfield, database router,|  Unreviewed
  multiple database  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mandm:

Old description:

> I'm trying to add a UUIDField in an existing user model following this
> method (with unique=True & default=uuid.uuid4).
> https://docs.djangoproject.com/en/1.11/howto/writing-migrations
> /#migrations-that-add-unique-fields
>
> This works with a single database but hangs in the following scenarios
> with multiple databases :
>
> - Hangs
>   - python manage.py migrate --database=nondefault
>   - also hangs with `.using('nondefault')` in the query in gen_uuid
> function
>
> - Works
>   - python manage.py migrate
>   - python manage.py migrate --database=default
>
> It seems to always hang at this statement `UserModel.objects.all()` when
> a non-default database is used either via `--database` option in migrate
> or via `.using('nondefault')` in query.
>
> Here's a snippet of the code I've used. I would be glad to provide
> additional information to reproduce the issue.
>
> User model :
>
> {{{
> class CustomUser(AbstractUser):
> address = models.TextField()
> uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)
>
> class Meta:
> db_table = 'customuser'
> }}}
>

> Migration file
>

> {{{
> def gen_uuid(apps, schema_editor):
> UserModel = apps.get_model('myapp', 'customuser')
> for row in UserModel.objects.all(): #
> .objects.using('foobar').all(): -- HANGS !
> row.uniq_id = uuid.uuid4()
> row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
> -- HANGS with database routers !
>
> class Migration(migrations.Migration):
> dependencies = [
> ('myapp', '003_previous_migration'),
> ]
>
> operations = [
> migrations.AddField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, null=True),
> ),
> migrations.RunPython(gen_uuid,
> reverse_code=migrations.RunPython.noop),
> migrations.AlterField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, unique=True),
> ),
> ]
> }}}

New description:

 I'm trying to add a UUIDField in an existing user model following this
 method (with unique=True & default=uuid.uuid4).
 https://docs.djangoproject.com/en/1.11/howto/writing-migrations
 /#migrations-that-add-unique-fields

 This works with a single database but hangs in the following scenarios
 with multiple databases :

 - Hangs
   - python manage.py migrate --database=nondefault
   - also hangs with `.using('nondefault')` in the query in gen_uuid
 function

 - Works
   - python manage.py migrate
   - python manage.py migrate --database=default

 It seems to always hang at this statement `UserModel.objects.all()` when a
 non-default database is used either via `--database` option in migrate or
 via `.using('nondefault')` in query.

 Here's a snippet of the code I've used. I would be glad to provide
 additional information to reproduce the issue.

 User model :

 {{{
 class CustomUser(AbstractUser):
 address = models.TextField()
 uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)

 class Meta:
 db_table = 'customuser'
 }}}


 Migration file


 {{{
 def gen_uuid(apps, schema_editor):
 UserModel = apps.get_model('myapp', 'customuser')
 for row in UserModel.objects.all(): #
 .objects.using('nondefault').all(): -- HANGS !
 row.uniq_id = uuid.uuid4()
 row.save(update_fields=['uniq_id'])

 class Migration(migrations.Migration):
 dependencies = [
 ('myapp', '003_previous_migration'),
 ]

 operations = [
 migrations.AddField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, null=True),
 ),
 migrations.RunPython(gen_uuid,
 reverse_code=migrations.RunPython.noop),
 migrations.AlterField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, unique=True),
 ),
 ]
 }}}

--

-- 
Ticket URL: 

Re: [Django] #30431: Migration hangs on non default database (was: Migration hangs when using UUIDField with unique default value & multiple databases)

[Django]

#30431: Migration hangs on non default database
-+-
 Reporter:  mandm|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, uuid,| Triage Stage:
  uuidfield, database router,|  Unreviewed
  multiple database  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mandm:

Old description:

> I'm trying to add a UUIDField in an existing user model following this
> method (with unique=True & default=uuid.uuid4).
> https://docs.djangoproject.com/en/1.11/howto/writing-migrations
> /#migrations-that-add-unique-fields
>
> This works with a single database but hangs in the following scenarios
> with multiple databases :
>
> - Hangs ! Migration with option `--database=foobar`
> - Hangs ! Migration without option `--database=foobar`, but with
> `using('foobar')` in the query in gen_uuid function
> - Works ! Migration without option `--database=foobar`
>

> Here's a snippet of the code I've used. I would be glad to provide
> additional information to reproduce the issue.
>
> User model :
>
> {{{
> class CustomUser(AbstractUser):
> address = models.TextField()
> uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)
>
> class Meta:
> db_table = 'customuser'
> }}}
>

> Migration file
>

> {{{
> def gen_uuid(apps, schema_editor):
> UserModel = apps.get_model('myapp', 'customuser')
> for row in UserModel.objects.all(): #
> .objects.using('foobar').all(): -- HANGS !
> row.uniq_id = uuid.uuid4()
> row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
> -- HANGS with database routers !
>
> class Migration(migrations.Migration):
> dependencies = [
> ('myapp', '003_previous_migration'),
> ]
>
> operations = [
> migrations.AddField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, null=True),
> ),
> migrations.RunPython(gen_uuid,
> reverse_code=migrations.RunPython.noop),
> migrations.AlterField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, unique=True),
> ),
> ]
> }}}

New description:

 I'm trying to add a UUIDField in an existing user model following this
 method (with unique=True & default=uuid.uuid4).
 https://docs.djangoproject.com/en/1.11/howto/writing-migrations
 /#migrations-that-add-unique-fields

 This works with a single database but hangs in the following scenarios
 with multiple databases :

 - Hangs
   - python manage.py migrate --database=nondefault
   - also hangs with `.using('nondefault')` in the query in gen_uuid
 function

 - Works
   - python manage.py migrate
   - python manage.py migrate --database=default

 It seems to always hang at this statement `UserModel.objects.all()` when a
 non-default database is used either via `--database` option in migrate or
 via `.using('nondefault')` in query.

 Here's a snippet of the code I've used. I would be glad to provide
 additional information to reproduce the issue.

 User model :

 {{{
 class CustomUser(AbstractUser):
 address = models.TextField()
 uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)

 class Meta:
 db_table = 'customuser'
 }}}


 Migration file


 {{{
 def gen_uuid(apps, schema_editor):
 UserModel = apps.get_model('myapp', 'customuser')
 for row in UserModel.objects.all(): #
 .objects.using('foobar').all(): -- HANGS !
 row.uniq_id = uuid.uuid4()
 row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
 -- HANGS with database routers !

 class Migration(migrations.Migration):
 dependencies = [
 ('myapp', '003_previous_migration'),
 ]

 operations = [
 migrations.AddField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, null=True),
 ),
 migrations.RunPython(gen_uuid,
 reverse_code=migrations.RunPython.noop),
 migrations.AlterField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, unique=True),
 ),
 ]
 }}}

--

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

-- 
You received this message 

Re: [Django] #30429: Allow different response classes in render(). (was: Allow different response classes in render())

[Django]

#30429: Allow different response classes in render().
---+--
 Reporter:  bsolomon1124   |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  render | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Thanks for the ticket, however `render()` is a simple, straightforward,
 and two line shortcut. IMO we shouldn't add any complexity to it. Adding
 `klass` (or `response_class`) will require changes in documentation and
 can be confusing. Moreover I don't think that your use case is really
 common, because `render()` returns `HttpResponse`  since its introduction
 in b3d2091681d31bf2a6f8c4a1f9f1fb32393864c8 and as far as I'm concerned it
 is a a first request to change this.

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

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

Re: [Django] #30431: Migration hangs when using UUIDField with unique default value & multiple databases

[Django]

#30431: Migration hangs when using UUIDField with unique default value & 
multiple
databases
-+-
 Reporter:  mandm|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, uuid,| Triage Stage:
  uuidfield, database router,|  Unreviewed
  multiple database  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by mandm:

Old description:

> I'm trying to add a UUIDField in an existing user model following this
> method (with unique=True & default=uuid.uuid4).
> https://docs.djangoproject.com/en/1.11/howto/writing-migrations
> /#migrations-that-add-unique-fields
>
> This works with a single database but hangs in the following scenarios
> with multiple databases :
>
> - Migration without `--database=foobar` works
> - Migration with `--database=foobar` option hangs
> - Migration without `--database=foobar`, but with `using('foobar')` in
> the query in gen_uuid function hangs
>

>
> Here's a snippet of the code I've used. I would be glad to provide
> additional information to reproduce the issue.
>
> User model :
>
> {{{
> class CustomUser(AbstractUser):
> address = models.TextField()
> uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)
>
> class Meta:
> db_table = 'customuser'
> }}}
>

> Migration file
>

> {{{
> def gen_uuid(apps, schema_editor):
> UserModel = apps.get_model('myapp', 'customuser')
> for row in UserModel.objects.all(): #
> .objects.using('foobar').all(): -- HANGS !
> row.uniq_id = uuid.uuid4()
> row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
> -- HANGS with database routers !
>
> class Migration(migrations.Migration):
> dependencies = [
> ('myapp', '003_previous_migration'),
> ]
>
> operations = [
> migrations.AddField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, null=True),
> ),
> migrations.RunPython(gen_uuid,
> reverse_code=migrations.RunPython.noop),
> migrations.AlterField(
> model_name='customuser',
> name='uniq_id',
> field=models.UUIDField(default=uuid.uuid4, unique=True),
> ),
> ]
> }}}

New description:

 I'm trying to add a UUIDField in an existing user model following this
 method (with unique=True & default=uuid.uuid4).
 https://docs.djangoproject.com/en/1.11/howto/writing-migrations
 /#migrations-that-add-unique-fields

 This works with a single database but hangs in the following scenarios
 with multiple databases :

 - Hangs ! Migration with option `--database=foobar`
 - Hangs ! Migration without option `--database=foobar`, but with
 `using('foobar')` in the query in gen_uuid function
 - Works ! Migration without option `--database=foobar`


 Here's a snippet of the code I've used. I would be glad to provide
 additional information to reproduce the issue.

 User model :

 {{{
 class CustomUser(AbstractUser):
 address = models.TextField()
 uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)

 class Meta:
 db_table = 'customuser'
 }}}


 Migration file


 {{{
 def gen_uuid(apps, schema_editor):
 UserModel = apps.get_model('myapp', 'customuser')
 for row in UserModel.objects.all(): #
 .objects.using('foobar').all(): -- HANGS !
 row.uniq_id = uuid.uuid4()
 row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
 -- HANGS with database routers !

 class Migration(migrations.Migration):
 dependencies = [
 ('myapp', '003_previous_migration'),
 ]

 operations = [
 migrations.AddField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, null=True),
 ),
 migrations.RunPython(gen_uuid,
 reverse_code=migrations.RunPython.noop),
 migrations.AlterField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, unique=True),
 ),
 ]
 }}}

--

-- 
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 

Re: [Django] #26488: migrate crashes when renaming a multi-table inheritance base model

[Django]

#26488: migrate crashes when renaming a multi-table inheritance base model
-+-
 Reporter:  Christopher  |Owner:  nobody
  Neugebauer |
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 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 felixxm):

 * status:  new => closed
 * resolution:   => duplicate
 * needs_tests:  1 => 0


Comment:

 Adding `migrations.AlterModelBases()` to a migration `operations` from
 [https://github.com/django/django/pull/11222 patch] proposed for #23521
 fix this issue for me, e.g.
 {{{ #!python
 operations = [
 migrations.AlterModelBases('suba', (models.Model,)),
 migrations.RenameModel(
 old_name='Base',
 new_name='BrokenBase',
 ),
 migrations.RenameField(
 model_name='suba',
 old_name='base_ptr',
 new_name='brokenbase_ptr',
 ),
 ]
 }}}
 Marking as a duplicate of #23521.

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

Re: [Django] #29529: Allow FilePathField path to accept a callable.

[Django]

#29529: Allow FilePathField path to accept a callable.
-+-
 Reporter:  Sebastiaan Arendsen  |Owner:  Mykola
 |  Kokalko
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration,   | Triage Stage:  Accepted
  filepathfield, makemigrations  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"ef082ebb84f00e38af4e8880d04e8365c2766d34" ef082ebb]:
 {{{
 #!CommitTicketReference repository=""
 revision="ef082ebb84f00e38af4e8880d04e8365c2766d34"
 Fixed #29529 -- Allowed models.fields.FilePathField to accept a callable
 path.
 }}}

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

[Django] #30431: Migration hangs when using UUIDField with unique default value & multiple databases

[Django]

#30431: Migration hangs when using UUIDField with unique default value & 
multiple
databases
-+-
   Reporter:  mandm  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  1.11
  Migrations |   Keywords:  migrations, uuid,
   Severity:  Normal |  uuidfield, database router,
   Triage Stage: |  multiple database
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm trying to add a UUIDField in an existing user model following this
 method (with unique=True & default=uuid.uuid4).
 https://docs.djangoproject.com/en/1.11/howto/writing-migrations
 /#migrations-that-add-unique-fields

 This works with a single database but hangs in the following scenarios
 with multiple databases :

 - Migration without `--database=foobar` works
 - Migration with `--database=foobar` option hangs
 - Migration without `--database=foobar`, but with `using('foobar')` in the
 query in gen_uuid function hangs



 Here's a snippet of the code I've used. I would be glad to provide
 additional information to reproduce the issue.

 User model :

 {{{
 class CustomUser(AbstractUser):
 address = models.TextField()
 uniq_id = models.UUIDField(unique=True, default=uuid.uuid4)

 class Meta:
 db_table = 'customuser'
 }}}


 Migration file


 {{{
 def gen_uuid(apps, schema_editor):
 UserModel = apps.get_model('myapp', 'customuser')
 for row in UserModel.objects.all(): #
 .objects.using('foobar').all(): -- HANGS !
 row.uniq_id = uuid.uuid4()
 row.save(update_fields=['uniq_id']) # .save(using='foobar', ...)
 -- HANGS with database routers !

 class Migration(migrations.Migration):
 dependencies = [
 ('myapp', '003_previous_migration'),
 ]

 operations = [
 migrations.AddField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, null=True),
 ),
 migrations.RunPython(gen_uuid,
 reverse_code=migrations.RunPython.noop),
 migrations.AlterField(
 model_name='customuser',
 name='uniq_id',
 field=models.UUIDField(default=uuid.uuid4, unique=True),
 ),
 ]
 }}}

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

Re: [Django] #30396: Add a system check for uniqueness of partial indexes and constraints names.

[Django]

#30396: Add a system check for uniqueness of partial indexes and constraints 
names.
-+-
 Reporter:  felixxm  |Owner:  Can
 Type:   |  Sarıgöl
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"bceadd2788dc2dad53eba0caae172bd8522fd483" bceadd27]:
 {{{
 #!CommitTicketReference repository=""
 revision="bceadd2788dc2dad53eba0caae172bd8522fd483"
 Fixed #30396 -- Added system checks for uniqueness of indexes and
 constraints names.

 Co-Authored-By: Mariusz Felisiak 
 }}}

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