Changes between Version 19 and Version 20 of FDORfc16

Timestamp:

03/29/08 12:17:54 (17 years ago)

Author:

traianstanev

Comment:

--

FDORfc16

@@ -90 +90 @@
 This is a new provider, so there will be no issues with backwards compatibility. We need to coordinate with the GDAL/OGR project (and any other data access libraries that express an interest) to make sure the metadata and geometry formats are usable cross-platform.
 
+== Implementation Plan ==
+
+This section goes into some detail about how FDO constructs will be implemented with a SQLite back end.
+
+1. Spatial Context
+
+In FDO schemas, the spatial context association of geometry properties is the string name of the spatial context. This will have to be mapped to an SRID integer, which is what the spatial_ref_sys table and geometry_columns table use to link geometry column to its spatial ref sys.
+
+2. FDO Data type mappings
+
+SQLite only supports integer, real, string and blob data types. All integer FDO data types will map to SQLite integers. Double and Single will map to Real. DateTime will map to a string, using ISO 8601 standard date time format. Decimal maps to Real. BLOB and geometry map to BLOBs and strings map to string.
+
+3. Insert command
+
+The provider will feature the following peculiarity of the Fdo Insert command implementation: if you reuse the same FdoIInsert instance to insert several features, these will be inserted within the same SQLite transaction, which closes when the command object is disposed. Inserts are extremely slow in SQLite unless they are batched into a single transaction, and this behavior of insert will help bulk feature inserts. 
+
+4. Select and Select Aggregate filters
+
+Initially, FDO filters will be converted to SQL where clauses directly using the !ToString() method. Therefore, any functions used within the clause need to be available or registered with the SQLite SQL engine. SQLite does have a way to bind external functions to the SQL engine, which is how we can implement most of the FDO expression functions (like sin, cos etc).
+
+There will be code which detects and extracts BBOX spatial conditions from the filter before doing the above conversion to string. The provider will use its spatial index  evaluate the spatial component of the filter. The SQLite SQL engine will be used for evaluating the remaining part of the filter.
+
+This approach is the same as the one used in the OGR provider.
+
+5. Multithreading
+
+The provider will not be multi-threaded. For simulataneous access, to the same database, one would have to open two connections. 
+
+6. Spatial Index
+
+The provider will initially use an in-memory spatial index, built up during the first spatial filter request. Serialization of the spatial index is possible, but will not be initially implemented. Once we have spatial index serialization, multiple connections will be able to use the same index via memory mapping. Until then, each connection will have its own spatial index. Due to 5., this may end up consuming more memory than it should.
+
+7. !ApplySchema
+
+The initial implementation of !ApplySchema will allow addition of new feature classes, but not modification of existing ones. If a feature class specified in the ApplySchema schema already exists, it will be skipped.
+
+8. !CreateDataStore
+
+This command will create a new sqlite database and also create empty spatial_ref_sys and geometry_columns table. If the database file already exists, the two tables will be created in the existing database.
+
+9. Autogenerated ID
+
+The provider will not support composite keys. The recommended key will be auto-increment integer (32 or 64 bit). This will map directly to the internal SQLite row id. It will be possible to use other key types via the SQL UNIQUE constraint on the key column.
+
+
+10. SQLite library
+
+Some modifications to and creative uses of SQLite's VDBE (SQL engine) will be necessary in order to improve read performance. Therefore the provider will use its own copy of SQLite. Note that this does not affect the file format in any way, just improves read performance when reading from within an FdoIFeatureReader.
+
+
+
 == Test Plan ==