FDO RFC 16 - FDO Provider for SQLite ¶

This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.

Status ¶

RFC Template Version	(1.0)
Submission Date	2008-03-18
Last Modified	Traian Stanev 2008-03-18
Author	Traian Stanev
RFC Status	draft
Implementation Status	under development
Proposed Milestone
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1

Overview ¶

This RFC proposes a new FDO provider for accessing (spatial) data stored in SQLite database files.

Motivation ¶

SQLite is an efficient and popular way to store data. Support for accessing SQLite databases via FDO would expand the range of data sources supported by FDO.

Proposed Solution ¶

The proposed SQLite provider will have the following features:

• Data stored and consumed in native SQLite format, and therefore accessible to other SQLite-based applications;
• Geometry will be serialized as BLOBs in FDO geometry format (FGF). Other ways that may be considered are storing points as X,Y columns and also geometry as WKB format;
• A non-persistent, spatial index usable for BBOX queries built on the fly and valid for the duration of the FDO connection;
• Execution of arbitrary SQL commands;
• A metadata table where the geometry coordinate system is stored in WKT or EPSG form. In addition, PRJ files will be supported as alternative means of specifying a coordinate system when a metadata table is undesirable;
• A tentative list of supported FDO commands : DescribeSchema, Select, SelectAggregates, Insert, Update, Delete, GetSpatialContexts, arbitrary SQL, ApplySchema, CreateDataStore;

FDO features the provider will likely *not* support:

• Feature class inheritance;
• Geometry filters other than BBOX;
• FDO Transactions -- but you can still manually execute BEGIN/COMMIT around other FDO commands;
• Associations;
• Constraints;
• Any other exotic feature you can think of.

Implications ¶

This is a new provider, so there will be no issues with backwards compatibility.

Test Plan ¶

There will be a small test suite that tests often used functionality. Arbitrary SQL execution will not be tested extensively.

Funding/Resources ¶