[mapguide-dev] DescribeSchema

Haris Kurtagic haris at sl-king.com
Tue Sep 19 16:58:31 EDT 2006

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.


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.


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

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-internals/attachments/20060919/6c0d2e11/attachment.html

More information about the Mapguide-internals mailing list