[fdo-internals] FDO RFC 7 -
AddNewMethodstoFdoClassDefinition-Take II
Barbara Zoladek
barbara.zoladek at autodesk.com
Tue Jul 31 11:38:01 EDT 2007
The client application does not have to use it, can only expose it to
the user as a view-based class.
My response was to the question how the application can use it.
Barbara.
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Jason Birch
> Sent: Tuesday, July 31, 2007 11:07 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 7 -
AddNewMethodstoFdoClassDefinition-Take II
>
> These arguments really make me nervous, they point to the fact that
when
> using these method calls, the client must have an understanding of
what
> "Virtual" means in the context of each provider.
>
> If all this function is for is to allow the application user to
> differentiate between their views and their physical tables, then I
> understand this need (users don't care that it's an abstraction layer,
> they want to see their RDBMS objects), but if it is being used to
affect
> the behaviour of the provider then I would much prefer to see the
> capabilities exposed more explicitly rather than requiring each
> application to have a knowledge of the provider.
>
> Wow, that was way too long a sentence for this early in the morning;
> sorry :)
>
> Jason
>
> -----Original Message-----
> From: Barbara Zoladek
> Subject: RE: [fdo-internals] FDO RFC 7 - Add
> NewMethodstoFdoClassDefinition-Take II
>
> > I am trying to understand how FDO client application can use
> information
> > that FDO Class is based on RDBMS View ?
>
> Since the view updateability cannot be determined reliably, the
> application knowing that the class is based on the virtual object
would
> be able to prevent data editing. The alternative would be to let the
> user insert/update data and hit the error at the target datastore and
> tell user that the operation is invalid. That's not the right
approach.
> Another example could be the case when application is caching data and
> must keep caches is sync.
>
> > For RDBMS application View can be same as Table. Data can be
> modifided,
> > index created, triggers created, etc..
> > For application's there is no difference if data is coming from View
> or
> > Table.
>
> Well, not exactly. Only simple views are updateable. Views based on
> complex queries require instead-of-triggers to make them updateable.
You
> cannot determine if the view is updateable or not. True that for
> example, SQL Server allows creating an index (Oracle does not), but
> still it depends on the underlying database object.
>
> Thanks,
> Barbara.
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
More information about the fdo-internals
mailing list