[mapguide-internals] Proposed minor changes to RFC 9

[Jason Birch]

Hi Steve,
 
I'm not sure that I fully understand.  
 
The RFC adds a layer-based UpdateFeatures that only requires a PropertyCollection.  This isn't changing, right?  What's changing is how this is implemented in the back end?
 
My primary concern is how transactional logic is handled in the back end.  Does it automatically use transactions for providers that support it, and not for those that don't?
 
I'd also hesitate to deprecate something in the FeatureService when there are folks that are using it natively and might find the extra control of specifying the transaction mode useful (and worth any performance penalty).  Is there a downside to leaving the old method signature in place, and just adding a second supported signature?
 
Jason

________________________________

From: Steve Dang
Subject: RE: [mapguide-internals] Proposed minor changes to RFC 9

In addition:

I've found that MgLayer::UpdateFeatures will be slow because of the
overheads (additional requests from the web tier) that need to determine
the provider name and whether or not it supports transactions.

So, I propose to deprecate:

        MgPropertyCollection* MgFeatureService::UpdateFeatures(
                MgResourceIdentifier* resource,
                MgFeatureCommandCollection* commands,
                bool useTransaction);

and add:

        MgPropertyCollection* MgFeatureService::UpdateFeatures(
                MgResourceIdentifier* resource,
                MgFeatureCommandCollection* commands);

The MgLayer::UpdateFeatures will call this new method and all the
overheads above will be done on the server side.