[fdo-internals] RFC 23 for Review

Thu Jul 10 17:35:44 EDT 2008

Hi Robert,

A class definition on its own is incomplete without a reference to the schema that it belongs to.  To address this, the schema should also be returned when requesting a given class definition.  This is the reason for extending DescribeSchema to allow restricting the result to specific class definitions.

I agree that special casing for providers is not the most "attractive" approach.  Implementation will focus on the providers that will have the most benefit.  However all the providers must provide implementation, so non-supporting providers can just fallback on a full DescribeSchema. The returned value of SetFeatureClassNames will help the caller identify support for specifying class names.  For the providers that will not restrict the schema, the behaviour is the same as before.  Nothing is lost, but they just won't enjoy the benefits of obtaining a smaller subset of the schema.

Ronnie

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Thursday, July 10, 2008 12:23 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 23 for Review

You are right - a reader wouldn't work well if you can't get directly at a given class.

Wasn't there a proposal to have a different command that would retrieve a single class definition?  I think you proposal to add that to DescribeSchema was avoiding that. But by bringing the special case for provider that doesn't support it, it makes it less "attractive" as it is difiicult to figure out if the provider will support or not the specification of class in the DescribeSChema command.

RF

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Ronnie Louie
Sent: Thursday, July 10, 2008 12:49 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 23 for Review

Hi Robert,

You are correct in figuring that my intention to target the RDBMS providers was to limit the scope of the effort.  I like how your suggestion for making FdoIGetFeatureClasses return a reader can eliminate the need for changing the current DescribeSchema.

I can see how to enumerate the class names by iterating the reader, but it is not clear to me how to retrieve a specific class definition?  In other words, one would have to enumerate the class names first.  Then he must somehow rewind the reader to retrieve the definition for one of those classes?

Thanks
Ronnie

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert Fortin
Sent: Thursday, July 10, 2008 7:40 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 23 for Review

Although must provider do caching, it is not always the case and doesn't have to be.  It's a trade off that is directly related to performance.  I don't think it is a big issue to requrest the application to reinitialize itself after a schema modification.

The fact that there is currently only one command that require to get the entire schema is not efficient for all application because it requires a full reverse engineering of the entire database instead of requesting the information relevant at a given time.  For example, Mapguide doesn't have to get the entire schema as it works mostly with one at a time.

If the provider decide to do caching of the entire schema when only the class name are requested (as proposed by the RFC) or if caching is done on the first call, there won't be any benefit.  But it doesn't have to be this way.  In case it does just retrieve the name of the classes, there will be benefit for the application, saving the reverse engineering of the entire schema which - with large database - can be an overhead that doesn't have to be.

I agree with Harris and Bruno, it has to be consistant across the board. No distinction or special case between RBDMS and other provider although the benefit might be more significant for RBDMS provider.  I understand your strategy might be to limit the scope of the effort.  See a proposal below to get rid of this special case.

Comments on the proposed RFC below:

FdoIEnumerateFeatureClasses: for consistancy with existing command doing similar things in FDO

- The class should be named FdoIGetFeatureClasses (like FdoIGetSpatialContexts, FdoIGetLongTransactions)
- Execute could return a reader to enable iteration instead of a string collection.
- This return reader could by itself offer to return the class definition for a given class instead of going back to the DescribeSchema command.  This would also avoid the problem that you would be introducing by reducing the scope to only the RDBMS function because

1) The new command could be limited to a subset of provider and not expose by the ones where it less relevant.
2) No need to modify DescribeSchema command.
3) There won't be special case handling for DescribeSchema comamnd to limit the scope to RDBMS provider.

Robert

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Thursday, July 10, 2008 8:31 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 23 for Review

Hi Bruno,
I saw your post now and I see I wrote same thing as you did.

Yes, King.Oracle provider is caching schema. Although I needed to add
deep Copy of Schema from cache before returning it to caller because of
bug in MapGuide. It makes it little slower after that.
Problem was in case of multi-user updating of data trough MapGuide.
MapGuide is deleting and adding class from schema in one of functions.
And if another user would do edit in that timeslot, exception in
MapGuide..

It is like MapGuide would assume that for every DescribeSchema he would
get new instance of schema. That could be correct in a way but then
MapGuide as application should be written to reuse schema instead of
calling it in almost every function.

I personally think for every request for Describe Schema providers
should do exactly that (not caching) and applications should count on
that.

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Bruno Scott
Sent: Thursday, July 10, 2008 8:52 AM
To: fdo-internals at lists.osgeo.org
Subject: Re: [fdo-internals] RFC 23 for Review

Hi Ronnie,
I know a little about the PostGIS provider, and the PostGIS provider
caches
the schema description internally on the first connection. So the first
call
is slow but all subsequent access to the DescribeSchema command is as
fast
as possible because it does not make any access to the rdbms.
The drawback of this approach is when we make a modification in the
rdbms
schema, we have to restart the mapguide server to make it available.

I know also that when we make a modification in an oracle schema, we
have
also to restart the mapguide server. So i bet other provider use this
same
technique.

So i guess for all of these providers that implement schema description
cache, we wont have much performance improvement.

Bruno

Ronnie Louie wrote:
>
> Hi,
>
> RFC 23 (http://trac.osgeo.org/fdo/wiki/FDORfc23) has been posted.
This
> RFC proposes APIs for retrieving feature class information without
having
> to perform a full DescribeSchema.  The main benefit will be improved
> performance in applications connecting to RDBMS datasources.  Please
> review the proposal and reply to this list with your comments by July
15,
> 2008.
>
> Thanks
> Ronnie
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
>
>

--
View this message in context:
http://www.nabble.com/RFC-23-for-Review-tp18366282p18376986.html
Sent from the FDO Internals mailing list archive at Nabble.com.

_______________________________________________
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
_______________________________________________
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
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals