What is an appropriate place to commit FeatureEventsTest that tests FeatureStore interface of ShapefileDataStore for FeatureEvents fired by notification mechanism of FeatureListenersManager for autocommit and non-autocommit transactions? The autocommit transaction case fails right now because no one FeatureWriter in chain of writers for ShapefileDataStore sends events during feature modifications through FeatureStore.
Vitali. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Jody Garnett > Sent: Friday, June 08, 2007 10:04 PM > To: Vitali Diatchkov; geotools-devel > Subject: Re: [Geotools-devel] Auto-commit transaction in > *ShapeFileDatastore in GT 2.2.x > > Yeah we could add a "batch" mode - the resulting event ends up being > "something changed here is the bounding box" - basically the same event > AUTO_COMMIT listeners get after a transaction has committed on a > different thread. > > Thinking. > > Some FeatureSources implement their bulk operations (like addFeatures) > using a Transaction. This is fine .. the FeatureSource bulk operations > just lets you do regular stuff that you could do by hand with a > collection and iterator after all. > > If it was an acceptable fix we could look into doing this kind of thing > more often ... > Jody > > > Relatively to UDIG we have so many hacks and changed places in our > products > > (because of project requirements). One of the requirements is auto- > commit > > transaction, so we changed the code managing transactions(like > > UDIGFeatureStore, etc.). In this light UDIG itself is not touched by > this > > "bug", it means just that GeoTools misses something important in > specific > > cases.. > > > > I will take care next week about that issue. Debug more and give test > cases > > and small report.Anyway, from the point of view of different tasks and > > requirements and goals, it would be nice to have an API to switch of/off > > notification from DataStore/FeatureStore/.. API. Like we have this > > capability in EMF technology. One feature modification does not affect > the > > situation but bulk modification of hundred features in big shapefiles > may > > affect. > > > > Vitali. > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:geotools- > devel- > >> [EMAIL PROTECTED] On Behalf Of Jody Garnett > >> Sent: Thursday, June 07, 2007 5:51 PM > >> To: Vitali Diatchkov; Geotools-Devel list > >> Subject: Re: [Geotools-devel] Auto-commit transaction in > >> *ShapeFileDatastore in GT 2.2.x > >> > >> Yeah let;s make a test case for this ... to start out with we can call > >> the method XtestAutoCommitEventNotification (so it does not break the > >> build). I suspect that the event notificaiton only works on a > >> transaciton becasue that is how it was tested (ie on uDig using > >> transactions). The code as it stands now is *supposed* to send event > >> notification - so let's get that test case and a debugger and see what > >> we can see. > >> > >> You are aware that uDig stuffs a Transaction into all the layers? (Or > >> maybe it only does that on a layer by layer basis when you first start > >> to edit - or request a FeatureStore) You should not of ended up in the > >> situtation you describe ... so I am confused :-) > >> > >> The very last - "internal" FeatureWriter (ie the one that does the > work) > >> is supposed to throw the AUTO_COMMIT events... it is part of the API > >> contract with AbstractDataStore (as per the data store tutorial). > >> > >> Cheers, > >> Jody > >> > >>> Hi, Jody! Should I implement JUnit test? Give me a plan, I would like > to > >>> > >> do > >> > >>> it to test getting notifications in case of different transactions. > >>> > >>> Related to UDIG. In one of our projects the requirement was autocommit > >>> transaction in the map for all layers. Seems ShapefileDataStore does > not > >>> raise feature events when routines of FeatureStore are used and > >>> > >> autocommit > >> > >>> transaction is set. > >>> The reason is that events are raised in DiffFeatureWriter. But it is > not > >>> > >> in > >> > >>> the chain of writers when autocommit transaction is used. > >>> > >>> The obvious hack is to wrap the last FeatureWriter in chain of writers > >>> > >> being > >> > >>> used with autocommit transaction with something like DiffFeatureWriter > >>> > >> where > >> > >>> only notification mechanism is present. > >>> > >>> Vitali. > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:geotools- > >>>> > >> devel- > >> > >>>> [EMAIL PROTECTED] On Behalf Of Jody Garnett > >>>> Sent: Friday, May 25, 2007 8:47 PM > >>>> To: Vitali Diatchkov > >>>> Cc: geotools-devel@lists.sourceforge.net > >>>> Subject: Re: [Geotools-devel] Auto-commit transaction in > >>>> *ShapeFileDatastore in GT 2.2.x > >>>> > >>>> The DataStore is the gatekeeper of notification ... because you may > >>>> > >> have > >> > >>>> more than one FeatureStore created looking at the same information. > The > >>>> test cases cover this kind of stuff pretty well for transaction > >>>> independence; but uDig is the only application making use of events > >>>> right now (so often we end up finding "new" problems). > >>>> > >>>> Can we reproduce your problem with a test case please Vitali? What > you > >>>> describe is a bug ... and not one that is known to me. > >>>> > >>>> Cheers, > >>>> Jody > >>>> > >>>> Vitali Diatchkov wrote: > >>>> > >>>> > >>>>> Hello! > >>>>> > >>>>> If an auto-commit transaction is used in ShapeFileDatastore then > >>>>> > >> during > >> > >>>> any > >>>> > >>>> > >>>>> features modification FeatureListener[s] do not get any > >>>>> > >> notifications. > >> > >>>> Only > >>>> > >>>> > >>>>> if the transaction is non-auto-commit then DiffFeatureWriter and > >>>>> TransactionStateDiff contains the code to notify listeners. > >>>>> > >>>>> It causes UDIG, for example, not to re-render the layer where > features > >>>>> > >>>>> > >>>> were > >>>> > >>>> > >>>>> modified/added/removed (in case of shapefile). > >>>>> > >>>>> Am I right with this suspicion? Seems the notification mechanism is > >>>>> > >>>>> > >>>> spread > >>>> > >>>> > >>>>> among classes.. Isn't implementation of FeatureStore is the right > >>>>> > >> place > >> > >>>> to > >>>> > >>>> > >>>>> have notification mechanism and way to turn on/off, batch > >>>>> > >> notifications, > >> > >>>>> etc. ? No matter what is a nature of datastore, the FeatureStore > >>>>> implementation may collect necessary information from datastore > >>>>> > >> specific > >> > >>>>> implementation classes but send these notifications in a centralized > >>>>> > >>>>> > >>>> way. > >>>> > >>>> > >>>>> I did not look into JIRA yet, so may be this is a known issue. > >>>>> > >>>>> Vitali Diatchkov. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -------------------------------------------------------------------- > -- > >>>>> > >> -- > >> > >>>> - > >>>> > >>>> > >>>>> This SF.net email is sponsored by DB2 Express > >>>>> Download DB2 Express C - the FREE version of DB2 express and take > >>>>> control of your XML. No limits. Just data. Click to get it now. > >>>>> http://sourceforge.net/powerbar/db2/ > >>>>> _______________________________________________ > >>>>> Geotools-devel mailing list > >>>>> Geotools-devel@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >>>>> > >>>>> > >>>>> > >>>> --------------------------------------------------------------------- > -- > >>>> > >> -- > >> > >>>> This SF.net email is sponsored by DB2 Express > >>>> Download DB2 Express C - the FREE version of DB2 express and take > >>>> control of your XML. No limits. Just data. Click to get it now. > >>>> http://sourceforge.net/powerbar/db2/ > >>>> _______________________________________________ > >>>> Geotools-devel mailing list > >>>> Geotools-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >>>> > >>>> > >>> > >> > >> ----------------------------------------------------------------------- > -- > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> _______________________________________________ > >> Geotools-devel mailing list > >> Geotools-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >> > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
