= 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 [wiki:FDORfcs 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.6)|| ||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 There is no predicable pattern? There is no need to inject provider names into the naming. JDBC doesn't, ODBC doesn't, FDO Shouldn't. The PostGIS provider has already adopted this approach following this mailing list discussion[[BR]] [http://www.nabble.com/Is-there-a-Feature-class-naming-convention-to15021175s18162.html#a15021175][[BR]] [http://trac.osgeo.org/fdo/ticket/310][[BR]] == Proposed Solution == * Providers which don't support multiple schemas, should report the parent folder name, all their content lives in that single schema ( ie was default). * 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. * The tables in the user schema or single folder are exposed via an empty schema (default). * Class names for databases are normally tablename, unless qualified which then has ~COLUMN_NAME appended. (if the are multiple geometries, FDO requires to know which one is the identifier) * Class names for file based providers is based on their file name as current * Therefore, The empty schema ":watercourses" could be also just "watercourses" * Class names must be XML friendly (i.e. no '~') * Unspported characters get mapped to '_' (ie ';' becomes '_' as per PostgreSQL provider) which would result in * OSGEO.SHP returns filename (or dir:filename) * OSGEO.Gdal returns filename (or dir:filename) * OSGEO.OGR returns filename (or dir:filename) * KingOracle returns schema:tablename or if connected as "schema" then just tablename * MySql returns schema:tablename or if connected as "schema" then just tablename * SDF still returns what ever you like as a schema name This is intended to apply where possible for all providers, the above list is just an example == 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][[BR]] [http://geospatial.blogs.com/geospatial/access_to_spatial_data/][[BR]] [http://n2.nabble.com/Standardising-FDO-Schema-s-td2051792i20.html][[BR]]