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
> <[email protected] (mailto:[email protected])> wrote:
> >
> > On Wed, Nov 23, 2011 at 11:37 PM, Jody Garnett <[email protected]
> > (mailto:[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
