[fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite

Tue Apr 1 16:35:17 EDT 2008

Theoretically, if the SDF provider is modified to support the format exactly as specified in RFC16, for both input and output, there would be no need for a separate provider.

I will be OK with this approach as long as it is guaranteed to adhere to that format. It would be OK to have extra metadata tables as long as they are not required in order for people to make sense out of the data. For example -- no custom encodings for things like Boolean and DateTime, which SQLite does not support. Instead use ISO 8601 for date, for example. A lot more FDO-specific stuff would need to be documented on top of that. There would also be implementation issues, like how to use SQLite column indexes in the SDF query executor, since SDF would not be using the SQLite execution engine. Also, would things like constraints use FDO metadata or SQLite metadata?

So to sum up, in theory I admit that it is possible to make SDF use this format and call it, say SDF4. In practice this will not be easy to do and at the same time stick to both the SDF spirit (superset of all FDO functionality) and the SQLite interchange format (extreme simplicity).

Traian

> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Jason Birch
> Sent: Tuesday, April 01, 2008 3:43 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>
> I don't see any problem SDF being "the" reference implementation of FDO
> (though it certainly has some deficiencies in this area), and it may be
> that SDF could benefit from some of the performance techniques that
> Traian is using.  It worries me that a data-agnostic project like FDO
> would require that its reference implementation be the fastest or most
> widely adopted provider though.  The goals of completeness and
> specialization are not always compatible with each other.  I'm guessing
> that you've read this:
>
> http://www.databasecolumn.com/2007/09/one-size-fits-all.html
>
> This can easily be extrapolated to spatial data access as well.  A
> provider tuned for rapid bounding-box fetches may not necessarily be
> the
> best provider to use for a multi-writer situation.  A provider with a
> simple metadata schema may not best reflect the richness of the FDO
> schema capabilities.
>
> For me, the new format has a different value proposition than SDF, and
> I
> don't fully accept the argument that if it meets a need that SDF does
> not that it will supersede SDF.
>
> I know that performance is Traian's main concern, but what I like most
> about this new format is that it is easily adopted by other data access
> libraries.  I don't see this same adoption happening with the SDF file
> format because it is closely aligned with FDO, is not accessible to the
> native SQLite tools, and there is no published specification to work
> to.
> I believe that these interchange points alone are justification for a
> new provider / data format.
>
> Jason
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: Tuesday, April 01, 2008 11:42
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>
> I agree. I would also prefer to see SDF maintained and promoted as the
> "official" FDO file format.
>
> Greg
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Badreddine
> Karoui
> Sent: Tuesday, April 01, 2008 2:25 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>
> That's how the SDF provider started: it did simple things realy good
> and
> then it took 3 years to get where it is now. It would probably need a
> couple of development(not prototyping) weeks to get it to create SQLite
> data.
>
> IMO. We are embarking on an other journey that will eventually create
> an
> other SDF provider. Except, that will be some X years down the road.
> And
> of course, create confusion around the FDO SDF file format.
>
> I'd rather see SDF maintained and promoted as the "official" FDO file
> format.
>
> 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: Tuesday, April 01, 2008 2:02 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>
> Survival of the fittest? :)
>
> This is a pretty common situation in open source development.  New
> approaches are developed independently without the legacy constraints
> of
> existing solutions, and if the approach is successful the existing
> technology either adapts or is superseded.  This allows new ideas to be
> explored without disrupting the current code base and requiring
> maintenance of backwards-compatibility code for dead-end ideas.
>
> I feel that requiring the simple RFC16 ideas to work within the SDF
> framework would slow development and testing of this new approach, and
> would require design compromises to meet the current needs of the SDF
> provider.  I would be much happier to see the proposed provider put out
> there, and the SDF provider react (or not) depending on its adoption.
>
> Jason
>
> -----Original Message-----
> From: Greg Boone
> Subject: RE: [fdo-internals] Vote: FDO RFC 16 - FDO Provider for SQLite
>
> Well, from my perspective, if we go with this new format then we are in
> some manner making a statement that SDF is not sufficient and that this
> new provider is intended to be developed as an eventual replacement.
> Regardless of the intent right now, that will, in the end, be the
> result.
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals