FDO RFC 43 - Standard FDO Class Naming Conventions

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	(Date/Time submitted)
Last Modified	Zac Spitzer Timestamp
Author	Zac Spitzer
RFC Status	(draft)
Implementation Status	(pending)
Proposed Milestone	(3.5)
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)

Overview

"Schema

In RDBMS terms, a Schema is a collection of tables, indexes, views, etc. in a database. Feature and RDBMS schemas do not correspond 1:1.

A Feature Schema may be stored in different RDBMS schemas and an RDBMS schema might be composed of multiple logical schemas."

http://fdo.osgeo.org/glossary.html

As a result of this loose definition we have no simple standard for schema and class naming across providers.

Motivation

FDO is meant to be a transparent data access layer, however, currently providers inject information into the FDO class names which make the same data in different datastores have different names.

Here are some examples of different schema & class names currently in use in FDO

OSGEO.SHP reports Default:shpfilename OSGEO.Gdal reports default:default KingOracle reports KingOra:ZAC~BUILDINGOUTLINES~SHPGEOM OSGEO.OGR reports OGRSchema:BUILDING MySql reports Fdoreports:aquifer_property

SDF reports what ever was set as the schema name

spot the pattern ?

I really don't see the need to inject provider names into the mix? ever.

PostGIS has been already meant updated following this mailing list discussion ​http://www.nabble.com/Is-there-a-Feature-class-naming-convention-to15021175s18162.html#a15021175 ​http://trac.osgeo.org/fdo/ticket/310

Proposed Solution

1. Providers which don't support multiple schemas, should report an empty schema,

all their content lives in that single schema ( ie was default).

2. Providers which have native schemas with multiple real schemas,

should represent those available schemas to GetSchemas unless over-ridden in the connection string or by custom mappings.

3. The tables in the user schema are listed in empty schema (default) conceptually

potentially twice.

4. Class names for databases are normally tablename, unless qualified which

then has ~COLUMN_NAME appended. (Coz if the are multiple geometries, FDO requires to know which one is the identifier)

5. Class names for file based providers is based on their file name as current

6. Therefore, The empty schema ":watercourses" could be also just "watercourses"

so lets see that means

OSGEO.SHP reports filename OSGEO.Gdal reports filename KingOracle reports schema:tablename or if connected as "schema" then just tablename OSGEO.OGR reports filename MySql reports schema:tablename or if connected as "schema" then just tablename SDF still reports what ever you like as a schema name

Implications

Each Provider would need to be updated to match the updated standard conventions

Test Plan

Expose the Sheboygan dataset via FDO matching the standard conventions

Funding/Resources

TBD

Links

​http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html
​http://geospatial.blogs.com/geospatial/access_to_spatial_data/
​http://n2.nabble.com/Standardising-FDO-Schema-s-td2051792i20.html