Re: [Django] #18368: LayerMapping.save() should be able to set attributes on created model instances

[Django]

#18368: LayerMapping.save() should be able to set attributes on created model
instances
-+--
 Reporter:  geoffhing@…  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  1.4
 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
-+--

Comment (by Austin Riba):

 I still think LayerMapping.save() at the least should return the saved
 object. I've run into the issue where I need to save data into the created
 object not in the shapefile, like the original author. Unlike the OP
 however a signal won't work (unless I'm missing something obvious) because
 the context needs to come from the import script, it can't be done in
 isolation.

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

Re: [Django] #28485: Stack trace report silently drops frames without source code

[Django]

#28485: Stack trace report silently drops frames without source code
---+--
 Reporter:  Martin von Gagern  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Error reporting|  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Martin von Gagern):

 * Attachment "f51ded156e1b8ef8b59bc10b01100de6c3021ab3.patch" added.

 GitHub8880.patch

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

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

[Django] #28485: Stack trace report silently drops frames without source code

[Django]

#28485: Stack trace report silently drops frames without source code
-+
   Reporter:  Martin von Gagern  |  Owner:  (none)
   Type:  Bug| Status:  new
  Component:  Error reporting|Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Recently I encountered a strange situation: I got an exception for a bad
 method signature, but the stack trace shown by Django in the error
 response did not even mention the method in question. I added a
 {{{traceback.print_exc()}}} to the last report function, and there on
 standard error I could see some more frames. They were without source
 code, but with file name, line number and method name. The reason why they
 were without source code was that their source was not directly accessible
 as a file on disk. They had been loaded via a custom loading procedure.
 The fact that there was no indication at all in the report was quite
 confusing.

 In [https://github.com/django/django/pull/8880 GitHub #8880] I'm proposing
 a fix for this. If we fail to load the source file, we no longer drop the
 frame but present what information we have, namely file name, line number
 and function name, plus a warning about the unavability of the source file
 in place of the actual source test.

 Note that having a [https://www.python.org/dev/peps/pep-0302/#optional-
 extensions-to-the-importer-protocol PEP 302] {{{__loader__}}} to the
 generated module to provide a {{{get_source}}} method is a way of
 supporting source code even for generated or custom-loaded code, and it is
 supported by Django. So this change here does not affect all generated or
 custom-loaded code, only those parts which don't make use of such a
 loader.

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

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

Re: [Django] #28484: QuerySet.extra keyword

[Django]

#28484: QuerySet.extra keyword
-+-
 Reporter:  Antonio Carrasco |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-
Changes (by Tim Graham):

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


Old description:

> Related to the #extra deprecation
> https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra
> Given this example:
>
> queryset = Model.objects.all()
> ordered_ids = "1,3,5,7"
> queryset.annotate(custom=RawSQL(f"SELECT FIELD(id, %s)",
> (ordered_ids,))).order_by("custom")
> queryset.extra(select={"custom": f"FIELD(id, {ordered_ids})"},
> order_by=[custom]).distinct()
>

> The result of both queries is different. But executing the ".query" query
> in the Mysql native console, the result is the same.
> The result with #extra is ok (the same the native mysql console returns)
> but the result with annotate is wrong.

New description:

 Related to the #extra deprecation
 https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra
 Given this example:
 {{{
 queryset = Model.objects.all()
 ordered_ids = "1,3,5,7"
 queryset.annotate(custom=RawSQL(f"SELECT FIELD(id, %s)",
 (ordered_ids,))).order_by("custom")
 queryset.extra(select={"custom": f"FIELD(id, {ordered_ids})"},
 order_by=['custom']).distinct()
 }}}
 The result of both queries is different. But executing the ".query" query
 in the Mysql native console, the result is the same.
 The result with #extra is ok (the same the native mysql console returns)
 but the result with annotate is wrong.

--

Comment:

 I'm unclear what the issue is here. It seems expected that the SQL will be
 different since one queryset uses `distinct()` and the other doesn't.
 Could you clarify why you believe Django is at fault?

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

Re: [Django] #28479: Document that transactions do not revert model state

[Django]

#28479: Document that transactions do not revert model state
-+-
 Reporter:  Todor Velichkov  |Owner:  Jonatas
 Type:   |  CD
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #28469: Add additional response type subclasses (was: Add "missing" response type subclasses)

[Django]

#28469: Add additional response type subclasses
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Old description:

> In the past Django has refused to add more HttpResponse subclasses to
> support all the codes listed in the  HTTP RFC, e.g. in #9943
> , HttpResponseNoContent in #3362, etc.
>
> A recent discussion on the django-developers mailing list (
> https://groups.google.com/forum/#!msg/django-
> developers/gnfX1m5jfm8/lMAucX_oBAAJ ) came to the consensus that adding
> them would be a win. It also pointed out existing implementations in
> django-extras, documented at https://django-
> extras.readthedocs.io/en/latest/ref/http-response.html .
>
> They should be added to Django core.

New description:

 In the past Django has refused to add more HttpResponse subclasses to
 support all the codes listed in the  HTTP RFC, e.g. in #9943,
 HttpResponseNoContent in #3362, etc.

 [https://groups.google.com/forum/#!msg/django-
 developers/gnfX1m5jfm8/lMAucX_oBAAJ A recent discussion] on the django-
 developers mailing list came to the consensus that adding them would be a
 win. It also pointed out [https://django-
 extras.readthedocs.io/en/latest/ref/http-response.html  existing
 implementations in django-extras].

 They should be added to Django core.

--

Comment:

 As I mentioned on the mailing list, I don't think we should add subclasses
 if they don't provide any functionality besides a different status code.
 For that, we could document this pattern:
 {{{
 from http import HTTPStatus
 HttpResponse(status=HTTPStatus.NO_CONTENT)
 }}}
 If a response subclass provides some other additional functionality, I'm
 open to adding it.

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

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

Re: [Django] #28481: migrate --fake produces stale content type warning when CreateModel exists in non-initial migration

[Django]

#28481: migrate --fake produces stale content type warning when CreateModel 
exists
in non-initial migration
+--
 Reporter:  Amanda Ng   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

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


Comment:

 I guess this is fixed in Django 1.11 because (quoting the 1.11 release
 notes) "The prompt for stale content type deletion no longer occurs after
 running the `migrate` command. Use the new `remove_stale_contenttypes`
 command instead." (#24865)

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

Re: [Django] #4518: Null string in DecimalField results in error: decimal.py _raise_error, line 2267

[Django]

#4518: Null string in DecimalField results in error: decimal.py  _raise_error,
line 2267
-+-
   Reporter:  Richard House  |Owner:  Adrian
    |  Holovaty
   Type: |   Status:  closed
  Component:  Core (Other)   |  Version:  master
   Severity: |   Resolution:  fixed
   Keywords:  DecimalField   | Triage Stage:
 |  Unreviewed
  Has patch:  0  |  Needs documentation:  0
Needs tests:  0  |  Patch needs improvement:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"bb91c0a4dcad89ec9ad14306e9708d11ea385444" bb91c0a4]:
 {{{
 #!CommitTicketReference repository=""
 revision="bb91c0a4dcad89ec9ad14306e9708d11ea385444"
 Refs #4518 -- Removed handling of empty strings in typecast_decimal().

 It's unclear if the original change was needed, but it seems unneeded now.
 Reverted 6fc10f50b0c9b877fffcad4893056cb91fa66b4f.
 }}}

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

Re: [Django] #28480: Nonstandard "minlength" property to

[Django]

#28480: Nonstandard "minlength" property to 
-+-
 Reporter:  Tomáš Pecina |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  minlength input  | Triage Stage:
  form field |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Replying to [comment:6 Tomáš Pecina]:
 > You think otherwise, and you are the boss here

 That's why I suggested the mailing list, so the decision could be
 discussed by more people than just one or two "bosses".

 > so I supressed the property manually in my code and this is the end of
 the story for me. Thanks for your time, anyway!

 If you found a solution working for you, that's great.

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

Re: [Django] #28480: Nonstandard "minlength" property to

[Django]

#28480: Nonstandard "minlength" property to 
-+-
 Reporter:  Tomáš Pecina |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  minlength input  | Triage Stage:
  form field |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tomáš Pecina):

 No, why? I simply think it's not a good idea to use automatically every
 property simply because it is there, and caution is needed because certain
 checks are better performed on the server (or by JavaScript) than in the
 browser. You think otherwise, and you are the boss here, so I supressed
 the property manually in my code and this is the end of the story for me.
 Thanks for your time, anyway!

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

Re: [Django] #28480: Nonstandard "minlength" property to

[Django]

#28480: Nonstandard "minlength" property to 
-+-
 Reporter:  Tomáš Pecina |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  minlength input  | Triage Stage:
  form field |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Tomáš, I'd suggest that you explain your issue on the django-developer
 mailing list.

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

Re: [Django] #28482: migrate --fake produces stale content type warning when CreateModel exists in non-initial migration

[Django]

#28482: migrate --fake produces stale content type warning when CreateModel 
exists
in non-initial migration
+--
 Reporter:  Amanda Ng   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.10
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  migrate fake stale  | 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:   => duplicate


Comment:

 Duplicate of https://code.djangoproject.com/ticket/28481

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

Re: [Django] #28483: Possible typo in Django 2.0 release notes regarding Python version support (was: Possible typo on the docs.djangoproject.com website)

[Django]

#28483: Possible typo in Django 2.0 release notes regarding Python version 
support
---+--
 Reporter:  Vasili Korol   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * type:  Uncategorized => Bug


Comment:

 It's correct as is. "Since Django 1.11" means "compared to Django 1.11."

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

Re: [Django] #24424: Removing a model's last field results in SQL syntax error

[Django]

#24424: Removing a model's last field results in SQL syntax error
--+
 Reporter:  Adam Hayward  |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  1.7
 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 direx):

 * cc: direx (added)


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

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

Re: [Django] #28484: QuerySet.extra keyword

[Django]

#28484: QuerySet.extra keyword
--+--
 Reporter:  Antonio Carrasco  |Owner:  nobody
 Type:  Uncategorized |   Status:  new
Component:  Uncategorized |  Version:  1.11
 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
--+--
Description changed by Antonio Carrasco:

Old description:

> Related to the #extra deprecation
> https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra
> Given this example:
>
> queryset = Model.objects.all()
> ordered_ids = "1,3,5,7"
> queryset.annotate(custom=RawSQL(f"SELECT FIELD(id, %s)",
> (ordered_ids,))).order_by("custom")
> queryset.extra(select={"custom": f"FIELD(id, {ordered_ids})"},
> order_by=[custom]).distinct()
>

> The result of both queries is different. But executing the
> .query.__str__() query in the Mysql native console, the result is the
> same.
> The result with #extra is ok (the same the native mysql console returns)
> but the result with annotate is wrong.

New description:

 Related to the #extra deprecation
 https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra
 Given this example:

 queryset = Model.objects.all()
 ordered_ids = "1,3,5,7"
 queryset.annotate(custom=RawSQL(f"SELECT FIELD(id, %s)",
 (ordered_ids,))).order_by("custom")
 queryset.extra(select={"custom": f"FIELD(id, {ordered_ids})"},
 order_by=[custom]).distinct()


 The result of both queries is different. But executing the ".query" query
 in the Mysql native console, the result is the same.
 The result with #extra is ok (the same the native mysql console returns)
 but the result with annotate is wrong.

--

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

[Django] #28484: QuerySet.extra keyword

[Django]

#28484: QuerySet.extra keyword
+
   Reporter:  Antonio Carrasco  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |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 |
+
 Related to the #extra deprecation
 https://docs.djangoproject.com/en/1.11/ref/models/querysets/#extra
 Given this example:

 queryset = Model.objects.all()
 ordered_ids = "1,3,5,7"
 queryset.annotate(custom=RawSQL(f"SELECT FIELD(id, %s)",
 (ordered_ids,))).order_by("custom")
 queryset.extra(select={"custom": f"FIELD(id, {ordered_ids})"},
 order_by=[custom]).distinct()


 The result of both queries is different. But executing the
 .query.__str__() query in the Mysql native console, the result is the
 same.
 The result with #extra is ok (the same the native mysql console returns)
 but the result with annotate is wrong.

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

[Django] #28483: Possible typo on the docs.djangoproject.com website

[Django]

#28483: Possible typo on the docs.djangoproject.com website
-+
   Reporter:  Vasili Korol   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:
   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  |
-+
 On the page with Django 2.0 release notes
 (https://docs.djangoproject.com/en/dev/releases/2.0/#python-
 compatibility), in the section "Python compatibility" at the top of the
 page, it is written:
 Django 2.0 supports Python 3.5+. Since Django **1.11**, support for
 Python 2.7 and 3.4 is removed.

 On the other hand, in the release notes for Django 1.11
 (https://docs.djangoproject.com/en/1.11/releases/1.11/#python-
 compatibility) it is stated:

 Django 1.11 requires Python 2.7, 3.4, 3.5, or 3.6. Django 1.11 is the
 first release to support Python 3.6. We highly recommend and only
 officially support the latest release of each series.The Django 1.11.x
 series is the last to support Python 2. The next major release, Django
 2.0, will only support Python 3.5+.

 Therefore, i believe, there is a typo in the Django 2.0 release notes, and
 it should read as ''"Since Django** 2.0**, support for Python 2.7 and 3.4
 is removed"''. Is this correct?

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

Re: [Django] #28479: Document that transactions do not revert model state

[Django]

#28479: Document that transactions do not revert model state
-+-
 Reporter:  Todor Velichkov  |Owner:  Jonatas
 Type:   |  CD
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jonatas CD):

 * has_patch:  0 => 1


Comment:

 Here is the [https://github.com/django/django/pull/8873 PR].

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

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

Re: [Django] #28479: Document that transactions do not revert model state

[Django]

#28479: Document that transactions do not revert model state
-+-
 Reporter:  Todor Velichkov  |Owner:  Jonatas
 Type:   |  CD
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jonatas CD):

 * status:  new => assigned
 * owner:  nobody => Jonatas CD


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

[Django] #28482: migrate --fake produces stale content type warning when CreateModel exists in non-initial migration

[Django]

#28482: migrate --fake produces stale content type warning when CreateModel 
exists
in non-initial migration
--+
   Reporter:  Amanda Ng   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.10
   Severity:  Normal  |   Keywords:  migrate fake stale
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When a new table creation is specified in a subsequent (i.e. non
 0001_initial.py) migration, and python manage.py migrate --fake is run, it
 prompts for deletion of the table as a "stale content type".

 Steps to reproduce:
 1. Create new project.
 2. Create new app.
 3. Create a table (e.g. class table1(models.Model)...) in app.
 4. Run "python manage.py makemigrations"
 5. Run "python manage.py migrate"
 6. Create a new table in app (e.g. class table2(models.Model)...) in app.
 7. Add foreign key to table 1 in table 2.
 8. Run "python manage.py makemigrations"
 9. Run "python manage.py migrate"
 10. Delete 0002_* entry from django_migrations table
 11. Run "python manage.py migrate --fake"

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

[Django] #28481: migrate --fake produces stale content type warning when CreateModel exists in non-initial migration

[Django]

#28481: migrate --fake produces stale content type warning when CreateModel 
exists
in non-initial migration
--+
   Reporter:  Amanda Ng   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  1.10
   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   |
--+
 When a new table creation is specified in a subsequent (i.e. non
 0001_initial.py) migration, and python manage.py migrate --fake is run, it
 prompts for deletion of the table as a "stale content type".

 Steps to reproduce:
 1. Create new project.
 2. Create new app.
 3. Create a table (e.g. class table1(models.Model)...) in app.
 4. Run "python manage.py makemigrations"
 5. Run "python manage.py migrate"
 6. Create a new table in app (e.g. class table2(models.Model)...) in app.
 7. Add foreign key to table 1 in table 2.
 8. Run "python manage.py makemigrations"
 9. Run "python manage.py migrate"
 10. Delete 0002_* entry from django_migrations table
 11. Run "python manage.py migrate --fake"

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

Re: [Django] #28480: Nonstandard "minlength" property to

[Django]

#28480: Nonstandard "minlength" property to 
-+-
 Reporter:  Tomáš Pecina |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  minlength input  | Triage Stage:
  form field |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tomáš Pecina):

 That's a good point, Claude. HOWEVER, we should realize that minlength is
 not the same thing as maxlength, conceptually, and browser developers are
 right in not implementing the former very eagerly. With maxlength, there
 is a clear and evident visual and possibly acoustic feedback: when the
 limit is reached, the user's keypresses are not displayed, and perhaps, a
 warning beep is produced. On the other hand, there is no such aid with
 minlength. Therefore, it might be wiser to let the Django validator do the
 job, and inform the user by a message such as "Currency code must consist
 of exactly three characters." By hardcoding the minlength property (which
 is not that easy to remove), we may be doing a disservice to the
 application developer. Please, give the issue a second thought.

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

Re: [Django] #28480: Nonstandard "minlength" property to

[Django]

#28480: Nonstandard "minlength" property to 
-+-
 Reporter:  Tomáš Pecina |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  minlength input  | Triage Stage:
  form field |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 https://validator.w3.org/nu/ does not complain. The latest draft of HTML
 5.2 on http://w3c.github.io/html/single-page.html does include the
 `minlength` attribute. I confirm this ticket's resolution. You may try
 opening a ticket in tidy bugtracker 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/067.54ee17343a74d93b87fe8cb002cd3aa0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.