introduce Ecto.Adapters.SQLite3.Extension

[aseigo]

This allows type extensions to be registered at runtime via the :ecto_sqlite3, extensions: configuration key, which takes a list of modules that implement the Extension behaviour.

See #166

This allows for an extension as simple as this to support storing and retrieving all the types in the geo library:

defmodule GeoSQL.SpatialLite.TypesExtension do
  @behaviour Ecto.Adapters.SQLite3.Extension
  @geo_types [
    Geo.GeometryCollection,
    Geo.LineString,
    Geo.LineStringZ,
    Geo.LineStringZM,
    Geo.MultiLineString,
    Geo.MultiLineStringZ,
    Geo.MultiLineStringZM,
    Geo.MultiPoint,
    Geo.MultiPointZ,
    Geo.MultiPolygon,
    Geo.MultiPolygonZ,
    Geo.Point,
    Geo.PointZ,
    Geo.PointM,
    Geo.PointZM,
    Geo.Polygon,
    Geo.PolygonZ
  ]

  @impl true
  def loaders(:geometry, ecto_type) do
    [&__MODULE__.decode_geometry/1, ecto_type]
  end

  def loaders(_primitive_type, _ecto_type) do
    nil
  end

  @impl true
  def dumpers(:geometry, ecto_type) do
    [ecto_type, &__MODULE__.encode_geometry/1]
  end

  def dumpers(_ecto_type, _primitive_type) do
    nil
  end

  def encode_geometry(%x{} = geometry) when x in @geo_types do
    case Geo.WKB.dec,encode(geometry) do
      {:ok, data} -> {:ok, data}
      {:error, _reason} -> :error
    end
  end

  #   def decode_geometry(<<len::integer-size(32), wkb::binary-size(len)>> = _data) do
  def decode_geometry(wkb) do
    case Geo.WKB.dec,ode(wkb) do
      {:ok, data} -> {:ok, data}
      {:error, _reason} -> :error
    end
  end
end

On a related note: this is still not sufficient to use with the SQL/MM GIS functions (the ST_* ones in SpatialLite), as while storing WKB works fine, Spatialite has it's own almost-but-not-quite-standard-wkb storage format (a truly daft idea) and has a few other minor incompatibilities such as seemingly not supporting SRID:<number> values in WKT/WKB ... so there's still some work to do to leverage this into full, proper Spatialite support ... but I'm working on that as a separate issue in another repo.

This is sufficient for serialization/deserialization of custom data types, however.

[aseigo]

It would have been nice to have this configurable on a per-Repo basis, but I was unable to find a (non-hacky) way to get at the repo configuration in the loaders/dumpers functions. If anyone has a bright idea there, please let me know!

[aseigo]

Update: I now have a working SpatialLite implementation using this PR :)

[aseigo]

On further investigation, this is not quite enough ... it works very nicely with Ecto, but any structs that are directly added to a query end up being passed directly to the exqlite driver. It seems it will also need to be instrumented, which may make this change moot .. or not. Will investigate further and follow up then.

[aseigo]

exqlite will require similar modifications. These changes are still required as well, but a similar set is needed in exqlite. So, this is back on the menu! ;) I will be submitting a PR to exqlite in a bit to get that moving as well.

[aseigo]

Small update: the exqlite PR was merged. With that and this PR, I have a fully operational Spatialite implementation! The same unit tests that test the PostGIS implementation now also work against a Spatialite DB.

If/when this PR is merged, I will publish that library on hex.pm :)

[aseigo]

If you'd like to play around with the Spatialite bits, the repository is here: https://github.com/expothecary/geo_sql

I finally got all the tests working this evening, which I wanted to get done before sharing it around. It needs more unit tests, but they will come. It's pretty neat to be able to use the same code for both PostGIS and Spatialite, so long as one sticks to the MM2, MM3, and Common functions.

But it works rather decently, all things considered.