Ticket #1394 (closed enhancement: fixed)

Opened 10 months ago

Last modified 7 months ago

MySQL Spatial extension support

Reported by: davehimself Owned by: jwage
Priority: minor Milestone: 1.1.0-ALPHA1
Component: Attributes Version:
Severity: Keywords:
Cc: Has Test: no
Status: Pending Core Response Has Patch: yes

Description

Currently the Data Dict for MySQL does not support the spatial extensions. generateModelsFromDb() will throw an exception and die when trying to reflect a table with a spatial field. I'm attaching a diff which can be applied to make the geometry type work. There are many other types which need to be implemented for full gis/spatial support.

Attachments

doctrine_gis.patch (104 bytes) - added by davehimself 10 months ago.
Patch to add Geometry type support for MySQL

Change History

Changed 10 months ago by davehimself

Patch to add Geometry type support for MySQL

  Changed 10 months ago by guilhermeblanco

  • status changed from new to closed
  • resolution set to fixed

(In [4858]) fixes #1394. Thanks for the patch!

  Changed 10 months ago by romanb

  • status changed from closed to reopened
  • resolution fixed deleted

geometry is no portable type. this patch is wrong.

follow-up: ↓ 4   Changed 10 months ago by davehimself

I feel that to say the patch is wrong is a little harsh. Not supporting this type is a show-stopper for me. I would hate to not be able to use Doctrine on account of a "non-portable type". IMHO, if Doctrine will not support "non-portable" types, then can the type abstraction be factored into classes with an API to allow users to define their own types? I looked for this functionality in the docs, but did not find it. I just assumed that it was not available.

in reply to: ↑ 3   Changed 10 months ago by romanb

Replying to davehimself:

I feel that to say the patch is wrong is a little harsh. Not supporting this type is a show-stopper for me. I would hate to not be able to use Doctrine on account of a "non-portable type". IMHO, if Doctrine will not support "non-portable" types, then can the type abstraction be factored into classes with an API to allow users to define their own types? I looked for this functionality in the docs, but did not find it. I just assumed that it was not available.

We are going to do sth like that in 2.0 (API for types and custom types). I am not sure at the moment how to deal with this in earlier versions like 1.0. Maybe we should open up the gates and just allow any kinds of column types, leaving the portability choice entirely to the user? We ended up doing this for functions in DQL, too, maybe we should do this here, too.

  Changed 10 months ago by romanb

Also, importing should already work (in the 1.0 branch). Theres nothing against importing a native type into a portable type (like blob).

  Changed 10 months ago by anonymous

  • milestone New deleted

Milestone New deleted

  Changed 9 months ago by jwage

  • version 0.11.0 deleted
  • milestone set to 1.1.0

  Changed 7 months ago by jwage

  • status changed from reopened to closed
  • resolution set to fixed

In r5232 this was fixed again. The last patch was not quite correct.

Note: See TracTickets for help on using tickets.