Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: 1.5.x
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
NOTE: first thing to do on the transaction reponse is to re-factor the code so its easy to understand (and not 800 lines long).
From jody (to track this issue):
I am writing up an article on TransactionResponse ... and I think I found a bug:
We start with an modifyFeatures - processing update elemet here:
if (types.length == 1)
{ store.modifyFeatures(types[0], values[0], filter); }else
{ store.modifyFeatures(types, values, filter); }Then we try and unlock the stuff that was justed changed:
if ((request.getLockId() != null)
&& store instanceof FeatureLocking
&& (request.getReleaseAction() == TransactionRequest.SOME))
Problem is we just changed the content, so that filter is not going to return the same set of features.
All is not lost, ealier we preprocessed the filter into a set of fids and bounding box. I think we could modify the code to operate with a new Filter constructed out of the Fid Set....
Jody