| Table of Contents |
|---|
...
| Case | Query one out of many using descendant cps path | Query one out of many using absolute cps path |
|---|---|---|
| Query | //openroadm-device[@device-id="C201-7-1A-14"] | /openroadm-devices/openroadm-device[@device-id="C201-7-1A-19"] |
| Comparison graph |
|
|
| Graph detail |
|
|
Time complexity of | O(N) | O(N) |
| Time complexity of proposed solution | O(N) | O(1) |
| Comments | The use of LIKE 'openroadm-device[%' in the query to match candidates | The use of the absolute path narrows the search space to only direct children of /openroadm-devices - for 3000 devices, we only need to scan 3000 fragments instead of 250k. |
...
This would give rise to constant time look up in such cases. If this solution is not implemented, users can work around this problem wrapping lists in container nodes, with the container being included in the descendant query, e.g. instead of //books[@title='Matilda'], change the model and use //books/book[@title='Matilda'] as a query. This would then have O(1) performance.
Note: if we wish to avoid creating additional database fields, using list/container name field would offer the best balance of performance, e.g.
| id | parent_id | anchor_id | xpath | container |
|---|---|---|---|---|
| 1 | NULL | 3 | /bookstore | bookstore |
| 2 | 1 | 3 | /bookstore/categories[@code='1'] | categories |
| 3 | 2 | 3 | /bookstore/categories[@code='1']/books[@title='Matilda'] | books |
| 4 | 2 | 3 | /bookstore/categories[@code='1']/books[@title='The Gruffalo'] | books |
In this case, attributes for any list element path component would need to be looked up (so it would no longer be index-only).
Work Breakdown for Implementation
...