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
