Skip to content
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
This repository was archived by the owner on Nov 9, 2017. It is now read-only.

SQL Syntax error when using YAML fixtures unless srid is present #24

Description

@haxney

I have a fixture defined like so:

one:
  long_name: Long Name
  short_name: LN
  bounds: !ruby/object:Polygon
    rings:
    - !ruby/object:LinearRing
      points:
      - !ruby/object:Point {x: 0, y: 0}
      - !ruby/object:Point {x: 20, y: 0}
      - !ruby/object:Point {x: 20, y: 20}
      - !ruby/object:Point {x: 0, y: 20}
      - !ruby/object:Point {x: 0, y: 0}

But trying to use it in a test suite results in the following error:

Mysql2::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '), 400743110)' at line 1: INSERT INTO `locations` (`long_name`, `short_name`, `bounds`, `id`) VALUES ('Positive Location', 'PL', GeomFromWKB(0x010300000001000000050000000000000000000000000000000000000000000000000034400000000000000000000000000000344000000000000034400000000000000000000000000000344000000000000000000000000000000000,), 400743110)

The key part of the problem is:

GeomFromWKB(0x01030000[...]0000,),

Where there is an extra comma inside the GeomFromWKB function call. Looking through the source, at lib/spatial_adapter/mysql2.rb:20 it looks like if value.srid is nil, then it would cause the erroneous SQL statement to be returned. I'm not sure how or why the srid isn't being set to DEFAULT_SRID when the object is being created, but if I manually set it in the YAML like so:

one:
  long_name: Long Name
  short_name: LN
  bounds: !ruby/object:Polygon
    srid: -1
    rings:
    - !ruby/object:LinearRing
      points:
      - !ruby/object:Point {x: 0, y: 0}
      - !ruby/object:Point {x: 20, y: 0}
      - !ruby/object:Point {x: 20, y: 20}
      - !ruby/object:Point {x: 0, y: 20}
      - !ruby/object:Point {x: 0, y: 0}

Then it works fine. Also, it doesn't need to be set in the child objects, since the GeoRuby srid= method takes care of propagating srid changes down through the tree.

This isn't the end of the world because of the simple workaround, but it does seem to go against the expected behavior.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions