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

[Robert Fortin]

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.

RF 

RF
--------------------------
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.

Barbara.

> -----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
FdoClassDefinition
> 
> 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
> 
> _______________________________________________
> 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/ee384f62/attachment.html