[fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

[Robert Fortin]

FDO has capabilities support mainly to have clients use them and react
differently depending on what the provider can support or do.  An
example: SupportsLock or SupportsLongTransaction which are capabilities
on a class definition.  This is not different. Maybe the methods should
be moved to the ClassCapability to make it more consistent.

Where I see we are breaking the line with this proposal is that we are
mixing logical and physical schema.  This barrier is usually bypassed by
providing schema mapping between the logical and physical schema.
DescribeSchemaMapping cna be use for that.  But there is no generic
interface define for it which means you are forced to link with a
specific provider to retrieve that information.  It makes the situation
even worst.  We don't want that.

RF


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, July 26, 2007 6:53 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to
FdoClassDefinition


But it sounds like the proposal is intended to allow the client to
bypass/break the abstraction that FDO provides in order to implement
behaviour that requires special knowledge of the providers.  In my
opinion, this is not a healthy thing to encourage in client
implementations.  If we continue to promote this, we'll end up with the
same problems as ODBC.  Would it not be possible to meet the specific
questions of the client in a more generic/abstract way?

Jason

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert
Fortin
Sent: Thursday, July 26, 2007 13:09
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to
FdoClassDefinition

The proposal is only to advertise the fact that some data comes from
view not that they are updatable or not. Frank would like to change it
for read-only property;  that is not what is currently proposed. 

It's up to the application to decide what to do with this property. For
example, the application might not allow to update on view-based class
because it can conflict with the actual feature class data.  The view
might still be updatable.

Also, the application don't have to react on it if they don't want to.
The application might not care about this property. It's different than
having a non-standard query per provider where the application is
enforced to do processing based on the provider connection.  It just
advertise some information hidden otherwise.

RF

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Thursday, July 26, 2007 2:03 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to
FdoClassDefinition

I don't think that I'm in favour of this RFC at first glance.

My main reason for this is that it requires the client to have special
knowledge about what IsViewBased means for each individual provider.
For instance, while Oracle allows updates to data in views in some
cases, PostgreSQL does not.  This makes FDO less pluggable, and defeats
the purpose of a common API.  It's the same reason I have a problem with
the non-standard query API for SDF; it requires special per-provider
logic on the client side.

I would personally prefer to see specific properties of the class that
reveal the information that IsViewBased is going to be used by the
client to obtain.

Jason

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Barbara
Zoladek
Sent: Thursday, July 26, 2007 10:30
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to
FdoClassDefinition

Absolutely! http://trac.osgeo.org/fdo/wiki/FDORfc7

Barbara.

> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals- 
> bounces at lists.osgeo.org] On Behalf Of Robert Fortin
> Sent: Thursday, July 26, 2007 1:26 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to
FdoClassDefinition
> 
> Can you add the link to the RFC page?
> Thanks!
> 
> RF
> 
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Barbara 
> Zoladek
> Sent: Thursday, July 26, 2007 1:25 PM
> To: fdo-internals at lists.osgeo.org
> Subject: [fdo-internals] FDO RFC 7 - Add New Methods to 
> FdoClassDefinition
> 
> Hi,
> 
> FDO RFC 7 has been posted for review.
> Please let me know if additional information about this enhancement is

> needed.
> 
> Thanks,
> Barbara.
> 
> _______________________________________________
> 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

_______________________________________________
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