CPS-309 - Getting issue details... STATUS


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 category has 'name' value. 'SciFi. The user wants to find a category with that name using

//category[@name='SciFi']

This means any xPath that ends-with a 'category' (list entry) that as an attribute of 'name' with value 'SciFi'

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. 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 attribute




  • No labels