[Mono-devel-list] DataView/DataRowView and event handlingissues

S Umadevi sUmadevi at novell.com
Wed May 19 23:33:31 EDT 2004


 Hi
   I have been trying to implement the dataview/datarowview and its
 related functionality...

Below is a text explaining my thoughts on this...

DataView & DataRowView & Event Notifications


This note explains problems with implementing the DataView and the
DataRowView classes.


The DataView represents a databindable, customized view of the
DataTable
for sorting, filtering,searching, editing etc.

The DataRowView represents a customized view of the DataRow that can
be
used with windows forms control.


A DataTable can have multiple DataViews. Operations on the DataView
and
the DataTable are reflected on each other based on the type of the
operations and when the commit /Accept changes is called.


The DataRowView almost similarly catering to DataRows except for the
fact that there can be only one be edited at a given point of time.
The
exisiting rowview that is being edited is saved.


The DataRow also allows manipulation of the row elements using Edit
functionalities.


Events to be handled.

Changes in the column, columncollection, dataset, datatablecollection,
constraint changes, list change events.


Since every table can have multiple views every time any of the events
that affect the view /rowview/row is received, there are many events
to
be received/notified into multiple datastrucutres/ objects.

Also the evaluation of the constraint and the constraint collection
changes also can trigger some of the events to generated.


In this context, the current problem is as follows.


Since every one of the above objects have their own datastructures,
notification on events has 2 fold problem

     1. The notification if done on a single thread from the
        notification generator makes it annoyingly slow for even
medium
        sized tables,
        
     2. The notification will also require synchronization of various
        data structures so that the data is consistent.
        
     3. Another point to be remembered is the fact that the there
could
        be multiple notifications that are generated out of different
        notifiiers into the same target. The notifiers can also get
        eventually blocked with too much of data or loss the data 
        
     4. The notification mechanism will have to either be a single
        queued mechanism (like the way Java does it) so that the
events
        are not lost and events not arriving in order of the
dispatching
        will cause more problems for the event receivers.
        
        


Approaches to solve this.


APPROACH 1 :

If a simple notification mechanism is built with the existing logic of
the datastructures we run into most of the problems mentioned above.
And
incase the size of data that is huge then we also notice
delays/bottlenecks in this approach. 

This approach is not very clean.. And has chances of breaking *



APPROACH 2

Have a event notification mechanism in place and then use it notify
events. This would atleast allow order of events.

But the flip side of this would be that the if we have a single thread
servicing them, there would be slowness in the response and the events
themselves reaching the receivers.

May be we can think of a thread pool to service requests here. Again
it
would be significant work to be done..


APPROACH 3

Have more leaner datastructures so that the updates are not required
in
as many places. Also this would reduce significant amount of
synchronization due to the multiple data structures working..


APPROACH 4 

Combination of 2 and 3 above, would be the cleanest..



But any of the above approaches would require significant code changes
and also testing. In the context of the current status of the project,
I
am wondering whether we want to take up any of the above.


Also incase of any suggestions / improvements / any other approach,
please let me know..
 



thanks
uma



More information about the Mono-devel-list mailing list