Re: [Geotools-devel] ContentFeatureStore transaction and event improvements

[Jody G. <jod...@gm...>]

Darn Andrea I was working on that today as well. I am going to see how much we overlapped. I moved Diff into ContentFeatureState; and was passing the ContentFeatureStore into the readers in order to handle event notification. 

I will try and review / merge your patch. 

-- 
Jody Garnett


On Sunday, 27 November 2011 at 1:16 AM, Andrea Aime wrote:

> On Thu, Nov 24, 2011 at 2:49 PM, Andrea Aime
> <and...@ge... (mailto:and...@ge...)> wrote:
> > 
> > On Wed, Nov 23, 2011 at 11:37 PM, Jody Garnett <jod...@gm... (mailto:jod...@gm...)> 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
> 
> -------------------------------------------------------