[fdo-internals] SQLite Provider issue

Badreddine Karoui badreddine.karoui at autodesk.com
Thu Jun 4 13:46:50 EDT 2009


As far as the SDF goes, the version of SQLite is not relevant since it's a low level implementation details. In another word, the SDF file is not an SQLite file. I don't think we should move the SDF provider to another version of SQLite.

Badreddine


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, June 04, 2009 1:32 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

So we're basically stuck with an old version of SQLite for the SDF format forever (or until we decide to rev SDF to version 4 or something)?

I agree that it wouldn't make sense to use an older version of SQLite for the SQLite provider.  My hope is that it will eventually read (though not optimally) other SQLite schemas such as SpatiaLite or just X/Y columns, and using an old version would constrain this potential.

Jason

-----Original Message-----
From: Badreddine Karoui
Sent: Thursday, June 04, 2009 10:24 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

It's the file generated by the SDF provider that has the binary compatibility issue; the latest SQLite library will not be able to read the files created by the SDF provider.

The SQLite provider takes advantage of new features provided by the latest SQLite library and it would not be a good idea to base the provider on an older version.

Badreddine


More information about the fdo-internals mailing list