Jira | ||||||
---|---|---|---|---|---|---|
|
Introduction
DB contains something like /bookstore/category[@code=01] 'code 'is the key for the list entry but there is also a 'name' attribute
user does NOT know the key value (or even what the key attribute is)
imagine Imagine category has 'name' value. 'SciFi. User The user wants to finds find a category with that name using
...
System COULD find out using models but the path is incomplete for more then than 1 match possible for 'category' in theory. But this might not be needed. Instead, the following steps will be used;
Alterative 1
...
Query Steps
- looks for xPath that ends with //category[@name='SciFi'] -> 0 results (existing behavior, no new code)
NEW
...
- CODE
- (if 0 results in step 1) look for xPath that ends with //category[
...
- @name=*]
...
- → (OPTIMISATION STEP - could go straight to step 3)
- 0 results -> 'name' is NOT the key, continue with step
...
- 3
...
- 1+ results 'name' is key but value not found, no need to continue
...
- ! (prevent unnecessary execution of step 3/performance hit , but need to document limitation if key-field for one list is non-key for other container with same name !
- Look
...
- for XPath that ends with //category[@*] AND attributes(jsonb) contains "name='SciFi'"
Note. the part for "attributes(jsonb) contains "name='SciFi'"" has already been implemented for another query
Alterative 2
Change step 1 above (legacy) code INTO step 3 so it will always look in the attributes jsonb no mater if it is a key filed or not
Pro : Less complex
Pro: No limitation on duplicate element names with same key/non-key field
Con: Performance hit when field happens to be the key
Con: Need support for composite key fields; existing attribute filter solution can only handle 1 attributethe f2nd