[fdo-internals] RFC 23 for Review
haris at sl-king.com
Thu Jul 10 08:31:08 EDT 2008
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
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
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
I know a little about the PostGIS provider, and the PostGIS provider
the schema description internally on the first connection. So the first
is slow but all subsequent access to the DescribeSchema command is as
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
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
also to restart the mapguide server. So i bet other provider use this
So i guess for all of these providers that implement schema description
cache, we wont have much performance improvement.
Ronnie Louie wrote:
> RFC 23 (http://trac.osgeo.org/fdo/wiki/FDORfc23) has been posted.
> RFC proposes APIs for retrieving feature class information without
> 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
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
View this message in context:
Sent from the FDO Internals mailing list archive at Nabble.com.
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals