GeoTools

Shapefile datastore should batch event notification.

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.2.2
  • Fix Version/s: 2.7.6
  • Component/s: shapefile plugin
  • Labels:
    None

Description

magine there is a filter based on BBOX in the layer from shapefile. When
I call FeatureStore.modifyFeatures(..., Filter) where I put new values for
the set of features filtered by Filter it causes rendering problems later
on. The reason: ShapefileDataStore (actually TransactionStateDiff) sends a
notification for every changed feature and this notification comes to the
Layer class through FeatureListener and causes re-rendering of the layer.
Shouldn't it be a batch notification from GeoTools stuff? Or should events
be collected at the Layer's class level?
The first way constraints low level events making them batched that is not
appropriated for all cases where GeoTools is used. The second approach needs
a special event from low level GeoTools stuff that all modifications are
done and the Layer is able to send batched event to notify listeners
including re-rendering of the layer.

See boxselection_after.jpg where described effect of not batched
re-rendering is displayed as a result of current behavior.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jody Garnett added a comment -
This was not the design; the notification was intended to let a cache stay in sync with the contents if needed. When produced we expected the modification to occur on a transaction; and any rendering to be done on Transaction.AUTO_COMMIT - in which case a "batch" would of occured out of the box for free.
Show
Jody Garnett added a comment - This was not the design; the notification was intended to let a cache stay in sync with the contents if needed. When produced we expected the modification to occur on a transaction; and any rendering to be done on Transaction.AUTO_COMMIT - in which case a "batch" would of occured out of the box for free.
Hide
Permalink
Jody Garnett added a comment -
I would assume a client would use those notifications to build up an invalid area and schedule it for a redraw; the down side of drawing the content as it is modified is that you get told about the content being modified.

Reading between the lines here it would be nice is we acknoldged our high level "batch opperations" with a event notification of their own. I would not be against this as we do our best to treat these operations as atomic (even to the point of breaking out a Transaction for them when we are in AUTO_COMMIT mode so we can roll them back as a unit).

The suggestion does however drastically complicate the event space; unless we play by the same non detailed rules that Transaction does. Ie we already "sum up" a modification on a Transaction in terms of a refresh event with a bounding box; as long as this level of detail is sufficient to keep a cache valid we would be in good shape.
Show
Jody Garnett added a comment - I would assume a client would use those notifications to build up an invalid area and schedule it for a redraw; the down side of drawing the content as it is modified is that you get told about the content being modified. Reading between the lines here it would be nice is we acknoldged our high level "batch opperations" with a event notification of their own. I would not be against this as we do our best to treat these operations as atomic (even to the point of breaking out a Transaction for them when we are in AUTO_COMMIT mode so we can roll them back as a unit). The suggestion does however drastically complicate the event space; unless we play by the same non detailed rules that Transaction does. Ie we already "sum up" a modification on a Transaction in terms of a refresh event with a bounding box; as long as this level of detail is sufficient to keep a cache valid we would be in good shape.
Hide
Permalink
Jesse Eichar added a comment -
There are a couple problems I see right now with events as they stand:
1. If we are firing events for each feature changed then there is no way to know when a "group" of changes ends. This is what is driving the desire for batch events.
2. Some datastores can't fire events for every feature changed. For example the WFS's implementation of Delete just sends the filter to the server with the request. For the API to be satisfied a getFeature request must be sent first before the delete. This turns an efficient operation into a really expensive operation. Current WFS implementation just fires an event with a null envelope to indicate "something" changed. As a seperate issue it should be considered that the the event should have the filter of the changed features since the BBox is usually a super-set of the features that have changed.
Show
Jesse Eichar added a comment - There are a couple problems I see right now with events as they stand: 1. If we are firing events for each feature changed then there is no way to know when a "group" of changes ends. This is what is driving the desire for batch events. 2. Some datastores can't fire events for every feature changed. For example the WFS's implementation of Delete just sends the filter to the server with the request. For the API to be satisfied a getFeature request must be sent first before the delete. This turns an efficient operation into a really expensive operation. Current WFS implementation just fires an event with a null envelope to indicate "something" changed. As a seperate issue it should be considered that the the event should have the filter of the changed features since the BBox is usually a super-set of the features that have changed.

People

  • Assignee:
    Jesse Eichar
    Reporter:
    Jesse Eichar
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: