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

Robert Fortin robert.fortin at autodesk.com
Fri Jul 27 12:23:48 EDT 2007

As Barbara said, we woud like to advertise the fact that a class is a combination of other classes.

The use case; make a distinction in the application between the general class and this type of class. In our case we would like to indicate to the user by using a different icon in the UI. Simple use case but we have no way to find this info at the moment.

It might be possible to use a different term that could include OGR concept and view concept.  I would not got as far a introducing an interface/type over FeatureClass though.


Sent from my BlackBerry - Please excuse typo and syntax.

----- Original Message -----
From: fdo-internals-bounces at lists.osgeo.org <fdo-internals-bounces at lists.osgeo.org>
To: FDO Internals Mail List <fdo-internals at lists.osgeo.org>
Sent: Fri Jul 27 11:39:35 2007
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

The 'view' term may be not the most fortunate because it is immediately
associated with RDBMS views. It should indicate that this is a virtual
object in the datastore and therefore a class mapped to that object is
virtual too. And that class "virtuality" we wanted to expose. It is not
only about limitation, but also about dependencies. Class B may depend
on Class A, if Class B is based on the subset of data in Class A. Class
B disappears when Class A is dropped.


> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
> Sent: Friday, July 27, 2007 11:03 AM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] FDO RFC 7 - Add New Methods to
> Robert Fortin wrote:
> > It's up to the application to decide what to do with this property.
> > example, the application might not allow to update on view-based
> > because it can conflict with the actual feature class data.  The
> > might still be updatable.
> >
> > Also, the application don't have to react on it if they don't want
> > The application might not care about this property. It's different
> > 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
> left scratching my head as to it's purpose.  What's the point of a
> indicating something is a view when the application is still left
> what the implications of this are?
> And as a provider writer, how do I know what I should mark as a view
> drivers that aren't terrible RDBMS oriented, such as OGR?  For
> in OGR I have a concept of executing a somewhat arbitrary SQL query
> 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,
> _______________________________________________
> 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

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

More information about the fdo-internals mailing list