[fdo-internals] SQLite Provider issue

Badreddine Karoui badreddine.karoui at autodesk.com
Thu Jun 4 13:24:19 EDT 2009


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


-----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:17 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

By binary compatibility, do you mean that the compiled 3rd party dll wouldn't be readable by the SDF provider, or that generated SDF files wouldn't be readable by older SDF providers?

Would there be any way for 3.5 to standardise on a single (modified) SQLite library shared between both SDF and the SQLite provider?  That would at least get us down to one non-vanilla SQLite dependency.

Jason

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

The thirdparty SQLite library is an older version needed by the SDF provider. The SDF provider needs the older version for binary compatibility reason since the latest version used by the SQLite provider is not backward compatible to the version used by the SDF provider.

Badreddine


More information about the fdo-internals mailing list