Page History

Introduction

DB contains something like /bookstore/category[@code=01]    'code 'is the key for the list entry but there is also a 'name' attribute

...

System COULD find out using models but the path is incomplete for more 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

1. looks for xPath that ends with //category[@name='SciFi'] -> 0 results (existing behavior, no new code)
   
   NEW CODE 
   
   
2. (if 0 results in step 1) look for xPath that ends with //category[@name=*] →  (OPTIMISATION STEP - could go straight to step 3)
   1. 0 results -> 'name' is NOT the key, continue with step 3 
   2. 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 !
3. ) Looks 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

Com: Need support for composite key fields