dumpscript not working for gis data

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ./manage.py dumpscript apps_using_gis_field
2. No step 2

What is the expected output? 
I would expect to see the ewkt string for the data that have one.
What do you see instead?
Instead I see repr of this field. This cannot be used to recreate the data.

What version of the product are you using? On what operating system?
I a using a rev 47

You will find a patch that solve the problem I have tested it against
postgis and it work fine. There might be some side effect for people using
postgres without gis. 

Please provide any additional information below.

Original issue reported on code.google.com by yann.ma...@gmail.com on 15 Nov 2008 at 9:30

Attachments:

• dumpscript_gis_enabled.diff

[GoogleCodeExporter]

That looks fine, I've never actually used django gis in a project, so I haven't 
come
across this yet. I've just set up a regression test suite for dumpscript so 
I'll add
this now and let you check that the test covers everything it needs to.

Original comment by e.willha...@gmail.com on 16 Nov 2008 at 1:22

[GoogleCodeExporter]

Ok, I've added stubs for GIS tests to the testsuite (see issue #71).

The patch will need to conditionally import geodjango, so as not to break on 
systems
without a GIS database backend (eg sqlite3). Also, the three blocks can be 
combined
into one using a test like this: 
{{{
if models_gis and isinstance(field, (models_gis.PointField,
models_gis.LineStringField, models_gis.PolygonField)):
}}}

What about the other GeoDjango fields (MultiPointField, MultiLineStringField,
MultiPolygonField and GeometryCollectionField)? How do they need to be handled?

Original comment by e.willha...@gmail.com on 16 Nov 2008 at 5:54

[GoogleCodeExporter]

Hello,
This is what I call reactivity... Thank you for keeping the ball rolling. I am 
not
really sure about Multi*Field I guess a similar approach should be applicable.
However I haven't used them yet some I am not really sure. I will give it a try 
as
soon as you push this into trunk.

I think your idea to conditionally import geodjango is excellent.
--yml 

Original comment by yann.ma...@gmail.com on 16 Nov 2008 at 2:23

[GoogleCodeExporter]

Is there any chance of this patch hitting trunk any time soon?

Original comment by wiley.kestner on 16 Feb 2009 at 8:32

[GoogleCodeExporter]

From a quick look at it the patch seems appropriate.
But as far as i can see it needs to be updated with e.willhardy's comments.
(which are very easy to-do changes)

Secondly it would be nice to have an approach for Multi*Field's as well. 
Preferable
before the patch is pushed into svn)

Original comment by v.oostv...@gmail.com on 16 Feb 2009 at 10:42

• Added labels: Type-Enhancement, Needs-better-patch
• Removed labels: Type-Defect

[GoogleCodeExporter]

I was working on a regression test suite (#71), so that changes like this can be
fast-tracked, but it's getting difficult to make it work with various versions 
of django.

I think it would be fine to just check in the non-Multi fields now, and add 
them later.

Here is an updated patch, but I haven't tested it on a geodjango setup. Could 
you run
it on one of your systems and let me know if it's enough?

Original comment by e.willha...@gmail.com on 17 Feb 2009 at 12:40

Attachments:

• 72-dumpscript-geodjango.diff