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

Fri Jul 27 17:43:50 EDT 2007

I was thinking rather in terms of ‘making it a little more generic’ in order to cover this limited use case.

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Barbara Zoladek
Sent: Friday, July 27, 2007 3:06 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

I don’t think that it would be a good practice to overload that API. It should be more explicit.

Barbara.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Friday, July 27, 2007 2:54 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

Yes, but does it really matter for UI purposes? 

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Barbara Zoladek
Sent: Friday, July 27, 2007 12:40 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

No, it is not the same. Computed classes are transient whereas view-based classes are persistent.

Barbara.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Friday, July 27, 2007 12:28 PM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

“to advertise the fact that a class is a combination of other classes.”

Which makes me think the class “is computed”. In this case could we reuse the existing Get/SetIsComputed() ?

Dan.

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Friday, July 27, 2007 12:24 PM
To: fdo-internals at lists.osgeo.org
Subject: Re: [fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition

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/79764484/attachment-0001.html