On Thu, Nov 24, 2011 at 2:49 PM, Andrea Aime <[email protected]> wrote: > > On Wed, Nov 23, 2011 at 11:37 PM, Jody Garnett <[email protected]> wrote: >> >> I thought about that; and we have two ways to consider simple. I don't >> really want to stuff a Diff into ContentState that many implementations will >> ignore. Extra stuff you are not using does end up being complex as well. > > Most implemntations are simply not aware of the state class to start with, > adding a support for diffs there is not going > to get in the way and only adds a object pointer, so it's pretty light. > Much better than having to mess directly with something many people don't > need or don't understand (either transactions > being implemented by hand or events)
Hi, I've just attached a patch to GEOT-3955 for review: https://jira.codehaus.org/browse/GEOT-3955 https://jira.codehaus.org/secure/attachment/57923/geot-3955.patch The patch builds on top of what Jody proposed, simplifying it by avoiding the need to use a new ContentState subclass and the need for a new feature diff reader (the one we already had in the classpath seemed to fit the bill already). It also integrates everything into ContentFeatureStore/ContentFeatureSource making the property-ng transaction independence and shapefile-ng transaction tests pass. As for really new features the code has been improved to account for transactions in both the getBounds() and getCount() methods (this time the right way I hope, AbstractFeatureSource support was buggy). ContentFeatureSource has a new canTransact() method to advertise native transaction support. The code also provides hopefully correct event support within transactions, while event support outside of them is still missing. I guess we can add also a canFireEvents() method in ContentFeatureStore() that is going to be used for automatic event support. For the case where we don't have any transaction support either this is going to be easy (the wrapper I was talking about last time), however in case native transactions are supported I'm not sure... I guess in this case the store is also supposed to handle events itself? I guess it might make sense, if you support transactions natively then also native events throwing is implied, and the code will be written so that if you declare transaction support but not event support then a error will be thrown on ContentFeatureStore creation. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
