Hi,
I modified an protocol used for testing internally to use partial tables, using the following ArrayOptions attribute: partial=”true:200″>.
Initially I didn’t add the partial attribute to the view tables which refer to tables where you have the partial attribute. DIS also didn’t mark it as an error nor it gave an warning. The view tables are in the same element/protocol.
I was wondering if you have view tables in your protocol for tables that have the partial attribute, that these view tables also need to have the partial attribute or is this optional?
DIS and Protocol Dev guide should also then state this, since I didn’t find it immediately.
Hi,
The partial option is currently not supported for view tables.
To further elaborate on this:
To support proper paging, the DataMiner Agent hosting the view would have to know about all available entries matching the filter from all of the source elements, and then return just the information for the currently selected page.
That’s exactly what a view table was not meant for: a view is intended to gather information from multiple huge data sets without having all of that data in memory.
The only way to do consistent paging is for the view to have session information with a snapshot of all the matching rows for the filter being used, and then do paging on there.
If the number of rows is small (< 5000), it would be more efficient to just send them to the client in one go.
If the number of rows is large or huge, those session states would just cause high memory on the DataMiner Agent (also taking into account that sessions would be per client).
That makes it not straightforward or easy to support paging in table views.
Sub note: paging should only be considered for larger tables (e.g. with paging sizes of 1000, 2000, or even 5000 rows). Setting a page size to 200 is not realistic as a table of 1000 rows can still be displayed without a problem and it’s better then to leave the paging behind to have better performance.