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

[Dan Stoica]

I agree, the first thing that comes to mind is the views are RDBMS
specific while FDO is provider agnostic.

Secondly:
            /// Sets the value of m_IsViewBased. It is true if a class
is based on view; otherwise is false.
            /// This is an internal method that can only be called by
providers. Application should not use this method.
            /// 
            /// \return
            /// Returns nothing
            /// 
	        FDO_API void SetIsViewBased( bool value );

How do we enforce (see in red) this behavior since the method is public?

Thanks,
Dan.

-----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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20070727/db568dfb/attachment.html