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

[Frank Warmerdam]

Robert Fortin wrote:
> 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.

Robert,

With clarification on the semantics of the "is a view" property, I'm still
left scratching my head as to it's purpose.  What's the point of a flag
indicating something is a view when the application is still left guessing
what the implications of this are?

And as a provider writer, how do I know what I should mark as a view in
drivers that aren't terrible RDBMS oriented, such as OGR?  For instance,
in OGR I have a concept of executing a somewhat arbitrary SQL query which
produces a resultset with many properties of a view (it isn't a 1:1
analog of a table).  Is it reasonable for me to mark it as a view?

I think it is up job of the RFC proposer to make a convincing case for
the utility of this property.  Just saying some applications can ignore it
isn't sufficient.  I feel the property effectively muddies the waters
as I understand it so far, and that is a net negative for FDO.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org