Re: [Django] #31150: SELECT DISTINCT is not not so distict

2020-01-13 Thread Django
#31150: SELECT DISTINCT is not not so distict
-+-
 Reporter:  Johannes Hoppe   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 I really try but without a queryset I was not able to reproduce this
 issue.

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

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


Re: [Django] #28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' object has no attribute 'is_relation'

2020-01-13 Thread Django
#28073: RemoveField.state_forwards() crashes with AttributeError: 'NoneType' 
object
has no attribute 'is_relation'
-+-
 Reporter:  Logan Gunthorpe  |Owner:  Pallav Parikh
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => Pallav Parikh
 * status:  new => assigned
 * has_patch:  0 => 1
 * version:  1.11 => master
 * needs_tests:  0 => 1


Comment:

 [https://github.com/django/django/pull/12314 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.344bdf8ec92f6b712b454b3b189dbe8d%40djangoproject.com.


[Django] #31163: use filters after when case, the table is not reused.

2020-01-13 Thread Django
#31163: use filters after when case, the table is not reused.
-+-
   Reporter:  Ashe   |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  join
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 == Model
 {{{#!python
 class Device(models.Model):
 pass

 class DeviceItem(models.Model):
  device = models.ForeignKey(
 Device, on_delete=models.PROTECT, related_name='item_set')

 class DeviceItemLocationHistory(models.Model):
  device_item = models.ForeignKey(
 DeviceItem, on_delete=models.PROTECT,
 related_name='devicerequestitem_set')
 location = models.ForeignKey(Location, on_delete=models.PROTECT)
 prev = models.OneToOneField(
 'self', on_delete=models.PROTECT, blank=True, null=True)
 next = models.OneToOneField(
 'self', on_delete=models.PROTECT, blank=True, null=True)
 changed_on = models.DateTimeField(auto_now_add=True)

 class DeviceMoveRequest(models.Model):
 device_item = models.ForeignKey(
 DeviceItem, on_delete=models.PROTECT,
 related_name='location_history_set')
location_history = models.OneToOneField(
 'devices.DeviceItemLocationHistory', verbose_name='위치',
 on_delete=models.PROTECT,
 blank=True, null=True,
 )
 request_type = models.CharField(max_length=50)

 }}}

 == Query
 {{{#!python
 queryset = Device.objects.annotate(
 diligence_site_partition_id=Case(
 When(
 item_set__location_history_set__devicerequestitem__request_type=[
 'purchaserequest', 'storerequest',
 ],
 then=F('item_set__location_history_set__location_id'),
 ),
 When(
 
item_set__location_history_set__devicerequestitem__request_type='releaserequest',
 then=F('item_set__location_history_set__prev__location_id')
 ),
 output_field=IntegerField()
 )
 ).values(
 'diligence_site_partition_id',
 'item_set__device',
 ).filter(
 item_set__location_history_set__changed_on__year='2020',
 )
 }}}

 == SQL

 === I expected

 {{{#!sql
 SELECT `devices_deviceitem`.`device_id`,
CASE
WHEN `logistics_devicemoverequest`.`request_type` IN
 ('purchaserequest', 'storerequest')
THEN `devices_deviceitemlocationhistory`.`location_id`
WHEN `logistics_devicemoverequest`.`request_type` =
 'releaserequest' THEN T8.`location_id`
ELSE NULL ENDAS `diligence_site_partition_id`,
 FROM `devices_device`
  LEFT OUTER JOIN `devices_deviceitem` ON (`devices_device`.`id` =
 `devices_deviceitem`.`device_id`)
  LEFT OUTER JOIN `devices_deviceitemlocationhistory`
  ON (`devices_deviceitem`.`id` =
 `devices_deviceitemlocationhistory`.`device_item_id`)
  LEFT OUTER JOIN `logistics_devicemoverequest` ON
 (`devices_deviceitemlocationhistory`.`id` =
 `logistics_devicemoverequest`.`location_history_id`)
  LEFT OUTER JOIN `devices_deviceitemlocationhistory` T8
  ON (`devices_deviceitemlocationhistory`.`prev_id`
 = T8.`id`)
 WHERE (`devices_deviceitemlocationhistory`.`changed_on` BETWEEN '2019 - 12
 - 31 15:00:00' AND '2020-12-31 14:59:59.99')
 GROUP BY `devices_deviceitem`.`device_id`,
  CASE
  WHEN `logistics_devicemoverequest`.`request_type` IN
 ('purchaserequest', 'storerequest')
  THEN `devices_deviceitemlocationhistory`.`location_id`
  WHEN `logistics_devicemoverequest`.`request_type` =
 'releaserequest' THEN T8.`location_id`
  ELSE NULL END
 ORDER BY NULL;
 }}}

 === but not reuse table

 Unexpected join will occur.

 {{{#!sql
 SELECT `devices_deviceitem`.`device_id`,
CASE
WHEN `logistics_devicemoverequest`.`request_type` IN
 ('purchaserequest', 'storerequest')
THEN `devices_deviceitemlocationhistory`.`location_id`
WHEN `logistics_devicemoverequest`.`request_type` =
 'releaserequest' THEN T8.`location_id`
ELSE NULL ENDAS `diligence_site_partition_id`,
 FROM `devices_device`
  LEFT OUTER JOIN `devices_deviceitem` ON (`devices_device`.`id` =
 `devices_deviceitem`.`device_id`)
  LEFT OUTER JOIN `devices_deviceitemlocationhistory`
  ON (`devices_deviceitem`.`id` =
 `devices_deviceitemlocationhistory`.`device_item_id`)
  LEFT OUTER JOIN `logistics_devicemover

Re: [Django] #23916: makemigrations does not detect/like model name case changes

2020-01-13 Thread Django
#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  1.7 => master
 * needs_tests:  0 => 1


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

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


Re: [Django] #23916: makemigrations does not detect/like model name case changes

2020-01-13 Thread Django
#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * owner:  nobody => Adam (Chainz) Johnson
 * status:  new => assigned
 * has_patch:  0 => 1


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

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


Re: [Django] #31162: GIS error logging when using WKT string as input to filter() query. (was: GIS error logging when using WKT string as input to filter() query)

2020-01-13 Thread Django
#31162: GIS error logging when using WKT string as input to filter() query.
+
 Reporter:  Arno|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by felixxm):

 * type:  Uncategorized => Bug
 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

 > According to https://docs.djangoproject.com/en/2.2/ref/contrib/gis/db-
 api/#geometry-lookups passing WKT strings is allowed, but there's no
 mention of being able to pass a filename as parameter.

 Thanks for this report. Django tries to use a `GDALRaster` if you pass
 `bytes` or `str` and if conversion is not successful then uses
 `GEOSGeometry`.

 `GDALRaster` accepts a string representing a file path. I agree that we
 should restore
 
[https://github.com/django/django/commit/6f44f714c92d2966dca390ebd3054e5fb0bb0c80
 #diff-6fa0bf748827a59b6730835b5439ded8L69-L70 the previous check] to avoid
 logging:

 {{{GDAL_ERROR 4: b'LINESTRING(0 0, 1 1, 5 5): No such file or
 directory'}}}

 We should also protect `GDALRaster._del__()` to avoid:

 {{{GDAL_ERROR 10: b"Pointer 'hObject' is NULL in 'GDALGetDescription'.}}}

 Maybe:
 {{{
 @cached_property
 def is_vsi_based(self):
 return self._ptr and
 self.name.startswith(VSI_FILESYSTEM_BASE_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.43ca3b8f65c9f69ac863692eb8c955ac%40djangoproject.com.


Re: [Django] #29871: Resetting primary key for a child model doesn't work. (was: Resetting primary key for a child model doesn't work)

2020-01-13 Thread Django
#29871: Resetting primary key for a child model doesn't work.
-+-
 Reporter:  Victor Porton|Owner:  Chetan
 |  Khanna
 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:  2.1 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c3c15e8eac605fc2378dda980afcce24%40djangoproject.com.


[Django] #31162: GIS error logging when using WKT string as input to filter() query

2020-01-13 Thread Django
#31162: GIS error logging when using WKT string as input to filter() query
-+
   Reporter:  Arno   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  GIS|Version:  2.2
   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 executing a geometry lookup like
 `my_geo_model.objects.filter(my_geom__intersects=wkt_string)` (i.e. using
 a WKT string as value)  django.contrib.gis emits the following errors:

 {{{
 2020-01-13 10:16:07,145 - django.contrib.gis - ERROR - GDAL_ERROR 4:
 b'POLYGON ((1 1, 1 0, 0 0, 0 1, 1 1)): No such file or directory'
 2020-01-13 10:16:08,403 - django.contrib.gis - ERROR - GDAL_ERROR 10:
 b"Pointer 'hObject' is NULL in 'GDALGetDescription'.\n"
 }}}

 The reason is that if passed a string, the string is first treated as a
 potential filename which GDAL tries to open and fails ("no such file").
 Only then it is tried to open the string as WKT/GeoJSON etc. Older Django
 versions did not emit these errors. However, in commit 6f44f714c9 a check
 in django/contrib/gis/gdal/raster/source.py:69 whether the file exists was
 removed.

 Silencing all errors from django.contrib.gis is not really a feasable
 workaround, as it would mean silcencing interesting GIS errors too.

 According to https://docs.djangoproject.com/en/2.2/ref/contrib/gis/db-api
 /#geometry-lookups passing WKT strings is allowed, but there's no mention
 of being able to pass a filename as parameter.

 It's a bit unexpected that Django first tries to open a file before it
 checks whether the passed string is valid WKT/GeoJSON, and that using WKT
 results in error messages. Or am I misunderstanding the documentation and
 calling the API wrongly?

 Relevant parts of example source:

 {{{
 models.py:

 class Area(models.Model):
 area = models.PolygonField()

 settings.py:

 LOGGING = {
 'version': 1,
 'handlers': {
 'console': {
 'level': 'INFO',
 'class': 'logging.StreamHandler',
 },
 },
 'root': {
 'handlers': ['console'],
 'level': 'INFO',
 }
 }

 main.py:

 from app.models import Area
 Area.objects.filter(area__intersects='POLYGON ((1 1, 1 0, 0 0, 0 1, 1
 1))')
 }}}

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

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


Re: [Django] #12203: ManyToManyField with through model can't be used in admin

2020-01-13 Thread Django
#12203: ManyToManyField with through model can't be used in admin
-+-
 Reporter:  David Gouldin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  M2M, admin,  | Triage Stage:  Accepted
  through, through_fields|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sylvain Fankhauser):

 Unfortunately, the `auto_created=True` hack doesn't work if you want to
 use foreign keys to the `through` model. You'll get a `(fields.E300) Field
 defines a relation with model 'JobTitleExperienceThrough', which is either
 not installed, or is abstract`.

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

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


Re: [Django] #31160: admin base.css styling breaks nested ordered list numbering in admindocs

2020-01-13 Thread Django
#31160: admin base.css styling breaks nested ordered list numbering in admindocs
-+-
 Reporter:  Owen T. Heisler  |Owner:  Owen
 |  Heisler
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"77d335e5abec889b15323975187a8d5b10bfcb0f" 77d335e]:
 {{{
 #!CommitTicketReference repository=""
 revision="77d335e5abec889b15323975187a8d5b10bfcb0f"
 Fixed #31160 -- Fixed admin CSS for ordered lists' descendants in
 unordered 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4783533130b7816ce23b2f95e2307287%40djangoproject.com.