Menu
▾
▴
geotools-devel
|
From: Vitali D. <vi...@ar...> - 2007-05-18 18:24:49
|
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. |
|
From: Jody G. <jga...@re...> - 2007-05-25 17:47:22
|
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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Jody G. <jga...@re...> - 2007-06-07 16:20:45
|
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: geo...@li... [mailto:geotools-devel- >> bo...@li...] On Behalf Of Jody Garnett >> Sent: Friday, May 25, 2007 8:47 PM >> To: Vitali Diatchkov >> Cc: geo...@li... >> 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 >>> Geo...@li... >>> 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 >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > |
|
From: Jody G. <jga...@re...> - 2007-06-08 19:04:18
|
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: geo...@li... [mailto:geotools-devel- >> bo...@li...] 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: geo...@li... [mailto:geotools- >>>> >> devel- >> >>>> bo...@li...] On Behalf Of Jody Garnett >>>> Sent: Friday, May 25, 2007 8:47 PM >>>> To: Vitali Diatchkov >>>> Cc: geo...@li... >>>> 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 >>>>> Geo...@li... >>>>> 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 >>>> Geo...@li... >>>> 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 >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > |
|
From: Vitali D. <vi...@ar...> - 2007-06-19 17:53:42
|
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: geo...@li... [mailto:geotools-devel- > bo...@li...] 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: geo...@li... [mailto:geotools- > devel- > >> bo...@li...] 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: geo...@li... [mailto:geotools- > >>>> > >> devel- > >> > >>>> bo...@li...] On Behalf Of Jody Garnett > >>>> Sent: Friday, May 25, 2007 8:47 PM > >>>> To: Vitali Diatchkov > >>>> Cc: geo...@li... > >>>> 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 > >>>>> Geo...@li... > >>>>> 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 > >>>> Geo...@li... > >>>> 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 > >> Geo...@li... > >> 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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
|
From: Jody G. <jga...@re...> - 2007-06-19 17:56:21
|
We should commit it in the source folder of data; so it can be reused by the datastore implementators. This idea (a set of common conformance tests) has a jira issue somewhere already. Good bug hunting; I am afraid at the time the DataStores were written we did not have a user interface around to ensure the events worked correctly (glad to see it happening now). Cheers, Jody Vitali Diatchkov wrote: > 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. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X