[fdo-internals] RE: RFC Reminder

Jason Birch Jason.Birch at nanaimo.ca
Wed Aug 1 14:42:45 EDT 2007


Hi,
 
Yes, my comment wasn't really specific to the RFC.  I guess I'd just
like to see a practice that provider-specific functions are rationalized
into the well-known list as quickly as possible.  Otherwise it will be
difficult for clients to write good cross-provider code.
 
Jason

________________________________

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
Knoell
Sent: Wednesday, August 01, 2007 11:36
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: RFC Reminder



Hi Jason

 

Actually, this is how it is currently working. FDO provides a list of
well-known functions with defined signatures. This list may be
enhanced/reduced  by a provider if additional functions/signatures are
supported or not supported resp. The provider implements the execution
of the request. For example, a call to a expression function MOD may be
replaced with a call to the (native) "%" operator in the SQL Server
provider.

 

What the RFC proposes is to enhance a class used to define a expression
function to include a property that categorizes the function. This class
- for example - is used in FDO to define the list of well-known
functions.  The RFC does not change any current behavior.

 

Thanks

 

  Thomas

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Wednesday, August 01, 2007 11:44 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: RFC Reminder

 

I'm a little concerned about leaving the list of supported expressions
up to the provider.

 

I'd prefer to have these expressions and their signatures defined at the
FDO level in a generic way, and then allow each provider to implement
them or not.  Otherwise, we'll have clients having to write
provider-specific code to implement basically the same functionality.  I
can't think of a spatial example off the top of my head, but I'd hate to
have to use NVL for Oracle and COALESCE for PostgreSQL rather than NOT
IS NULL for both.

 

Or perhaps the current well known expressions could be expanded as
rapidly as possible, and arbitrate naming and signature differences as
they are encountered?  If two providers implement the same
functionality, then once the function is defined as well known one of
them could just write a stub translating the well known name/signature
into the proprietary version?

 

Jason

 

________________________________

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
Knoell
Sent: Wednesday, August 01, 2007 08:29
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: RFC Reminder

Hi Dan

 

Since the proposal is to enhance the create-methods, the default value
for the category parameter needs to be a neutral value like
FdoFunctionCategoryType_Unspecified to be backwards compatible.

 

I don't agree that FDO should have a function-to-category mapping. How
many functions should be part of the mapping structure? There are lots
of them in - for example - Oracle. Should they all be known to FDO and
mapped to a category? It is the provider that sets the list of supported
expression functions together with the supported signatures and at that
time the category may be set as well.

 

Thanks

 

  Thomas

 

 

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Wednesday, August 01, 2007 11:17 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: RFC Reminder

 

Also, the default value for the category is
FdoFunctionCategoryType_Unspecified;

 

I think it will be way better to use a hardcoded mapping {function_name,
function_category} in FDO. Example: "Max" will belong to "Math" etc.

Unless the caller decides to change it (in 0.01% of the cases) the
category input parameter is unused which makes life easier.

 

Dan.

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: Tuesday, July 31, 2007 5:55 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: RFC Reminder

 

Would it make sense to expand further Geometry Category with :

-          Spatial Aggregate Functions

-          Coordinate System Transformations Functions

-          Geocoding Functions

-          Geometry Functions

... ?

 

This is sample how Oracle Spatial divides Geometry Functions.

 

Haris

 

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
Knoell
Sent: Tuesday, July 31, 2007 11:42 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: RFC Reminder

 

Hi,

 

Thanks to everyone who provided comments on this RFC posting. Based on
the comments the RFC has been updated. Please review the new version of
the RFC and comment on it if required by end of the day tomorrow (August
1st). If no changes are required, I intent to motion that a vote for the
acceptance of the RFC is made and subsequently voted on by the PSC.

 

Thanks

 

  Thomas

 

From: Thomas Knoell 
Sent: Friday, July 27, 2007 11:13 AM
To: FDO Internals Mail List
Subject: RFC Reminder

 

Hi everyone

 

As indicated in an e-mail dated July 17th, FDO RFC 5
(http://trac.osgeo.org/fdo/wiki/FDORfc5) had been posted and is ready
for review. Please complete the review of the RFC and comment on it by
end-of-day Tuesday, July 31st. If no changes are required, it is my
intent to motion that a vote for the acceptance of RFC5 be made and
subsequently voted on by the PSC. 

 

Thanks

 

  Thomas

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070801/b98c91bb/attachment.html


More information about the fdo-internals mailing list