You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to determine the properties of a geometry column, the OID::Spatial#parse_sql_type method is called in the SchemaStatements#initialize_type_map method for geometry types. This method parses a sql_type (ex. "geometry(Polygon,4326)") and derives the geo_type, srid, has_z, has_m, and geographic properties from the string.
The problem is that after a join, sql_type comes in as "". This makes it impossible to determine any properties from it and the default properties are passed into the OID::Spatial constructor which can cause unexpected geometry types to appear.
In order to determine the properties of a geometry column, the
OID::Spatial#parse_sql_type
method is called in theSchemaStatements#initialize_type_map
method for geometry types. This method parses asql_type
(ex. "geometry(Polygon,4326)") and derives thegeo_type
,srid
,has_z
,has_m
, andgeographic
properties from the string.The problem is that after a join,
sql_type
comes in as "". This makes it impossible to determine any properties from it and the default properties are passed into theOID::Spatial
constructor which can cause unexpected geometry types to appear.Here is the place where the
sql_type
comes in.activerecord-postgis-adapter/lib/active_record/connection_adapters/postgis/schema_statements.rb
Lines 99 to 107 in 95be29d
This is likely some sort of upstream issue where the data in a join is not being passed properly.
The current workaround is to register an
attribute
on the target table (described in #334).The text was updated successfully, but these errors were encountered: