[fdo-internals] RFC 23 for Review

Thu Jul 10 18:11:16 EDT 2008

Hi Ronnie,
I asked before but could be that my question was lost in all that
discussion.

How would application know what schema name to use for new class
enumeration interface ?
Shouldn't we implement Schema enumerator interface also ?

So application could go like:
- get schemas
- for selected schemas get classes
- for selected classes get full class details

Haris

-----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 11:36 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RFC 23 for Review

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