[mapguide-dev] DescribeSchema

[Bruce Dechant]

MapGuide SP1 (1.1.0) which is about to be released has schema caching
(DescribeSchema, GetSpatialContext, etc...) and FDO connection pooling.
It is a lot faster then release 1.0.1. The code is already available in
the open source branch, but has not been back ported to the trunk yet.

 

Bruce

 

  _____  

From: Traian Stanev 
Sent: September 19, 2006 3:49 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema

 

Well, short of storing the FDO schema in an SDF provider-like blob
between connections, I don't have any other ideas on how to make
DescribeSchema faster in 1.0.1. :-)

 

  _____  

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Tuesday, September 19, 2006 5:40 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema

Thank you.

 

I am not just "looking" in instances of call. I've done a quite a few
testing and MG server does call DescribeSchema very often (refresh,
layer on, api calls etc...)

 

Caching inside connection doesn't help in 1.0.1 (because 1.0.1 is not
pooling connections).

 

thank you for suggestions and explanations.

 

Haris

 

  _____  

From: Traian Stanev [mailto:traian.stanev at autodesk.com] 
Sent: Tuesday, September 19, 2006 11:18 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema

 

The fact that there are several instances of calls to DescribeSchema
does not imply that that code actually gets called a lot during normal
operation of MapGuide. This is because the FeatureService is an API more
than anything else.

 

Personally, I would accept the fact that in a multithreaded environment,
an operation might fail if the schema changes underneath it and would
simply cache the schema once per open FDO connection, but that's my
personal opinion. Another option is to have some sort of a "read-only"
flag on the connection which you can use to determine whether to cache
the schema or not.

 

 

Traian

 

 

 

  _____  

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Tuesday, September 19, 2006 4:59 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema

What I was trying to say is that MapGuide server itself (server feature
service) is calling many times this command in fdo.

And also after getting it is doing a lot of "copying and.." and it takes
a lot of time MapGuide itself..

 

So If I cache it inside FDO provider it is little better, but not sure
also is it "right" to cache. In multithreaded enviroment I could imagine
some problems if schema is changing.

 

I am using 1.0.1 version.

 

Haris

  _____  

From: Traian Stanev [mailto:traian.stanev at autodesk.com] 
Sent: Tuesday, September 19, 2006 10:52 PM
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema

 

You are right. DescribeSchema is a major choke point for any code that
calls it a lot. It should be cached whenever possible. That said,
MapGuide is going to (or already has) some caching of the schemas, so
it's not that critical for the provider to have a fast DescribeSchema,
unless you are worried about code other than MapGuide. However, I would
argue that competently written FDO code already avoids repeated calls to
things like:

 

  * DescribeSchema

  * GetSpatialContexts

  * FdoIFeatureReader::GetClassDefinition

  * anything that converts FDO stuff to XML.

 

 

Traian

 

 

 

  _____  

From: Haris Kurtagic [mailto:haris at sl-king.com] 
Sent: Tuesday, September 19, 2006 4:25 PM
To: dev at mapguide.osgeo.org
Subject: [mapguide-dev] DescribeSchema

Hi,

 

Right now FDO command DescribeSchema is called many times while
describing Data Store and in another cases.

 

I have a question how should fdo provider react to this requests.

 

Is it supposed that provider will cach schema or is it supposed to allow
dinamicaly changing of schema (in underlaying RDBMS for example) or .. ?

 

Also as I see it, there is a lot of coping of fdo schema returned from
provider inside server, so it is very time consuming.

Not sure if I am looking right but it doesn't look good :)

 

Haris

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-internals/attachments/20060919/591abddb/attachment.html