#36129: Geodjango migrations ignore change of dimension in MultiPointField
------------------------------+--------------------------------------
     Reporter:  Paweł Kotiuk  |                    Owner:  (none)
         Type:  Bug           |                   Status:  closed
    Component:  GIS           |                  Version:  dev
     Severity:  Normal        |               Resolution:  invalid
     Keywords:  migrations    |             Triage Stage:  Unreviewed
    Has patch:  0             |      Needs documentation:  0
  Needs tests:  0             |  Patch needs improvement:  0
Easy pickings:  0             |                    UI/UX:  0
------------------------------+--------------------------------------
Changes (by Natalia Bidart):

 * cc: Claude Paroz (added)
 * keywords:   => migrations
 * resolution:   => invalid
 * status:  new => closed
 * type:  Uncategorized => Bug
 * version:  5.1 => dev

Comment:

 Hello Pawel, thank you for this report. I agree this is similar to the
 tickets you linked and also to #23902. Can you specify what backend are
 you using?

 Based on the previous tickets, and following the comments from Claude, it
 seems quite challenging to generate a migration that makes sense for the
 backend, in that how the added dimension would work with respect to the
 existing values in the DB? For your reproducer specifically, my
 understanding is that your last step works because the test DB is created
 with a single and "clean" migration where the `dim=3` since the start.

 Having said that, I have tried this in a test project and using the admin
 to create a point when `dim=2`. Then I changed to `dim=3` and the point
 was migrated in the DB as follows (this is PostGIS): `SRID=4326;MULTIPOINT
 Z ((-0.0051498413085937 0.0168228146996821 0))`. But I can't add new
 points because of the chosen default, which does not have the third
 dimension:

 {{{
 Exception Type: DataError at /admin/geodjangoapp/multipointtester/add/
 Exception Value: Column has Z dimension but geometry does not
 }}}

 So, I ''think'' that this specific report is about the default being
 incorrect for a 3-dimension multipoint (which would consitute an user
 error), and not so much about migration generation failure, but I'm not a
 GIS expert. I was going to propose for you to reach our in the forum, but
 I see you have already [https://forum.djangoproject.com/t/bug-geodjango-
 migrations-ignore-change-of-dimension-in-multipointfield/38169/2 done so].
 Because of my local testing, I'll be closing this ticket as invalid
 following the
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#closing-tickets ticket triaging process], but feel free to reopen
 if you find more specific information detailing that Django is at fault in
 this specific case, specifically once you remove the potentially incorrect
 default in place.

 Thanks again!
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36129#comment:2>
Django <https://code.djangoproject.com/>
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019494e9572e-05ba0e60-0d05-4687-8865-e0d7c03ba293-000000%40eu-central-1.amazonses.com.

Reply via email to