This class is used to implement the fetchMore method as an asynchronous operation.
More...
|
| def | __init__ (self, TreeNode node, _FetchCompletion._Context context) |
| |
| def | create_buffer_object (self, type) |
| | Create an object to use as a buffer via Python buffer protocol that will be passed to the underlying repository API for receiving data.
|
| |
| def | get_children_complete (self, path, dppaths, subpaths) |
| | Request completion handler for get_children requests.
|
| |
| def | get_children_failed (self, path, exception) |
| | Request completion handler for failed get_children requests, which resets the corresponding internal state variables.
|
| |
| def | read_meta_data_complete (self, path, metadata) |
| | Request completion handler for read_meta_data requests, which will update the internal tree node with the retrieved metadata.
|
| |
| def | read_meta_data_failed (self, path, exception) |
| | Request completion handler for failed read_meta_data requests, which resets the corresponding internal state variables for the node's metadata and value.
|
| |
| def | read_data_point_complete (self, path) |
| | Request completion handler for read_data_point requests, which checks if the fetch operation was cancelled, in which case the data is marked as stale.
|
| |
| def | read_data_point_failed (self, path, exception) |
| | Request completion handler for failed read_data_point requests, which resets the corresponding internal state variables for the node's value.
|
| |
| def | data_point_updated (self, path, value) |
| | This request completion handler will update the internal tree node with the retrieved data value.
|
| |
This class is used to implement the fetchMore method as an asynchronous operation.
This is done by having the signals produced by the RepositoryControl be delegated to the completion handler methods implemented in this class. Specifically, an instance of this class is created for every asynchronous request made to the RepositoryControl, and is passed as the tag field in the request. The same tag is returned in the signal handler, allowing us to associate each signal reply to its original request. To delegate the call, the slot methods (e.g. RepositoryModel.on_read_data_point_complete) for each RepositoryControl signal then simply call the corresponding completion handler method implemented in this class.
The completion handlers are coded to effectively implement the following steps to complete the whole fetchMore operation:
- Find all stale nodes that are supposed to be updated.
- Mark these nodes as requested.
- Send a get_children request for each non-leaf node to fetch the children.
- Send read_meta_data requests for leaf nodes (i.e. those tree nodes that actually correspond to datapoints in the repository) if the metadata is stale.
- Send read_data_point requests for leaf nodes that do not have stale metadata, but have their data values marked as stale.
- As get_children requests complete:
- Mark the non-leaf node as ready.
- Send secondary get_children requests for newly added non-leaf children, or read_meta_data requests for leaf children tree nodes. Note that we only send get_children requests to limit the recursion depth to 2 levels, i.e. up to grandchildren. This is because it allows QTreeView widgets to manage how deeply to fetch data with multiple calls to canFetchMore and fetchMore. At least 2 levels must be fetched to have enough information about the grandchildren for subsequent calls to rowCount and canFetchMore to return the correct information.
- As read_meta_data requests complete:
- Update the metadata in the leaf node.
- Mark the metadata as ready.
- Prepare a buffer object to receive the new value, now that we know the type information for the datapoint, which is part of the metadata.
- Send read_data_point requests to fetch the data value.
- As read_data_point requests complete:
- Update the data value in the leaf node.
- Mark the leaf node as ready.
- We keep track of all the requests made in a context object that is shared by all the _FetchCompletion instances corresponding to the same fetchMore operation. Once all the above requests have been completed, the whole fetchMore operation is considered complete.
It is important to correctly mark the nodes that will be handled by this fetchMore operation as requested. This makes sure that subsequent calls to fetchMore that start a new operation will not mistakenly try to handle the same nodes, i.e. this keeps multiple concurrent fetchMore operations from interfering with each other. Similarly it is important to mark nodes as ready once requests have completed.
There is also a cancellation mechanism: a cancelled flag is part of the common context. If this flag is set to True, only existing requests are allowed to complete, but no further requests are made. There is no rollback mechanism and a cancellation will leave the fetchMore operation only partially complete. However, the internal state of each tree node should still be consistent, i.e. what was partially completed should be marked as ready and nodes where a fetch was not finished should be marked as stale.
