[mapguide-dev] DescribeSchema
Jason Birch
Jason.Birch at nanaimo.ca
Tue Sep 19 18:32:50 EDT 2006
1.1.0 is SP1? I thought that there would be a 1.0.2...
________________________________
From: Bruce Dechant [mailto:bruce.dechant at autodesk.com]
Sent: Tuesday, September 19, 2006 14:54
To: dev at mapguide.osgeo.org
Subject: RE: [mapguide-dev] DescribeSchema
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/cb0501e8/attachment.html
More information about the Mapguide-internals
mailing list