[fdo-internals] xmin and xmax are reserved keywords

[Gavin Cramer]

Hi Mateusz.  I was just chatting with Brent, and it might be a lesser
change to make a provider-specific override to the setup functions for
the reader/writer classes (and an updated fdo_sys.sql as Brent mentions
below).

The "xmin" etc. names that appear in the code are mostly just internal
query field tags that could stay the same.  They are merely defaults to
the actual column names.  We'd need to make some currently non-virtual
methods virtual, such as the FdoSmPhMgr factory function for
FdoSmPhSpatialContextGroupWriter, but such changes are very minor.

Is this proposal less work?

Gavin


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Brent
Robinson
Sent: Monday, January 15, 2007 11:38 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] xmin and xmax are reserved keywords

Mateusz,

That would work for me. This issue is likely to come up again for future
providers, since other RDBMS's may also reserve some of the column names
currently in the FDO MetaSchema. Allowing the provider to customize the
MetaSchema table and column names would provide a relatively easy way to
resolve these issues. The MetaSchema tables are created by fdo_sys.sql
but, fortunately, provider-specific customizations to this file are
allowed.

Brent.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
Loskot
Sent: Monday, January 15, 2007 10:40 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] xmin and xmax are reserved keywords

Brent Robinson wrote:
> Hi Mateusz,
> 
> Does PostGIS support double quote delimiting for table and column
names
> in select statements?
> 
> If it does then another option might be to double-quote delimit these
> names in the select statements issued by the Schema Manager. This
would
> be a fairly small change to utilities/SchemaMgr/src/Ph/Field.cpp.

Brent,

As Paul already explained, it's not feasible.

What about a simple indirection - querying provider's Schema
manager for column name. For example:

1. ctor of FdoSmPhSpatialContextGroupReader already accepts physical
manager of given provider.

2. In the class FdoSmPhSpatialContextGroupReader, the pointer to this
manager could be saved.

3. Next, whenever functions like
FdoSmPhSpatialContextGroupReader::GetXMin() are called, first, the
reader asks physical manager for column name using ie. enumerator to
identify which column name is requested.
Here, I assume the set of column names in f_* meta schema is well-known
 and constant.

4. In the FdoSmPhMgr, we can add new API similar to GetDcColumnName() or
extend existing GetDcColumnName(), which can be called from GetXMin()
and return default *or* provider's specific column name.

5. If no implementation is provided by a FDO provider, then default
column name is returned by manager itself.

6. If a provider (re)implements the column name API in FdoSmPhMgr,
class, then provider's specific name is used in in the
FdoSmPhSpatialContextGroupReader class.

Would it work for you?


Cheers
--
Mateusz Loskot
http://mateusz.loskot.net
_______________________________________________
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