ContentFeatureStore should provide transaction support to implementors
The current code in ContentFeatureStore does not directly handle transactions, the class should probably roll a new "supportNativeTransactions" method and if those are not supported TransactionStateDiff should be brought into the picture for both writes and reads (the latter might be tricky with the usual "implement the source and have the store delegate to it approach").
Mass closing all resolved issues not modified in the last 4 weeks
CodeHaus Comment From: jgarnett - Time: Sun, 27 Nov 2011 08:37:41 -0600
r38380 - r38383
CodeHaus Comment From: jgarnett - Time: Sun, 27 Nov 2011 03:02:12 -0600
Andrea in email you indicated that uDig was the only code making use of these events. It mostly cares in order to update the screen efficiently.
I was wondering if we could refactor FeatureEvent to indicate the transaction as the source; and thus avoid having to throw the FeatureSource around the code base (when it is only used to construct a valid FeatureEvent). I can look into changing how uDig uses these events if it would result in a significant simplification of the GeoTools code.
CodeHaus Comment From: jgarnett - Time: Sun, 27 Nov 2011 02:40:27 -0600
I could not apply the patch smoothly as property-ng has been repackaged into org.geotools.data.property.ng.PropertyFeatureSource.
I will merge with my own work today; thus far it looks like I was mostly working on comments and API contract so we should be good.
After that was done and everything is working I was going to try and separate out the event support from the Diff support. Was this still the direction you wanted to take things? My initial implementation only had them tied together to minimise code changes during refactoring.
CodeHaus Comment From: aaime - Time: Sat, 26 Nov 2011 09:08:38 -0600
Complete patch based on Jody's work, but with less new classes, reuse of the old ones where possible, and removal of deprecated methods usage where possible.