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 Steps1)

1. looks for xPath that ends with //category[@name='SciFi'] -> 0 results (existing behavior, no new code)
   
   NEW CODE 
   

...

1. 
   
2. (if 0 results in step 1) look for xPath that ends with //category[@name=*] →  (OPTIMISATION STEP - could go straight to step 3)

   ...

   1. 1. 0 results -> 'name' is NOT the key, continue with step

   ...

   1. 1. 3 

   ...

   1. 1. 1+ results 'name' is key but value not found, no need to continue

   ...

   1. 1. ! (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 !
   2. Look

   ...

   1. 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 queryNote. Document limitations and existing cps path.

   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 attribute