Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

we would like to bring support for contains operator in cps-path. 

...

#

Issue

Notes

Decisions
1Which keyword to use ? Do we want case sensitivity or not? Do we follow the Xpath contains or do we become specific?
  • like %en% 
  • ilike %En% 
  • like 'en' 


  As per discussion , with Toine Siebelink  Prefers Contains Xpath is case sensitive , So ilike keyword would be suitable to implement the contains query , community call  like keyword would has consistency which support case sensitive attribute values.

Need to discuss with stakeholders.

  As per discussion in community call , decided to go with like  keyword more consistent support case sensitivity.


#

Json Data

CPS-PATH Syntax

Output

1

Below is the sample data ,
 Here  are ways  to use contains keyword :
Code Block
titleJson data
collapsetrue
{
   "test:bookstore":{
      "bookstore-name": "Chapters",
      "categories": [
         {
            "code": "01",
            "name": "SciFi",
            "books": [
               {
                  "authors": [
                     "Iain M. Banks"
                  ],
                  "lang": "english",
                  "price": "895",
                  "pub_year": "1994",
                  "title": "Feersum Endjinn"
               }
            ]
         },
         {
            "name": "kids",
            "code": "02",
            "books": [
               {
                  "authors": [
                     "Philip Pullman"
                  ],
                  "lang": "Science",
                  "price": "699",
                  "pub_year": "1995",
                  "title": "The Golden Compass"
               }
            ]
         }
    ]
   }
}


<cps-path>(contains'[@leafname,'<string-value>']')

Examples
  • //books[contains(@lang,'en')
  • //books[contains(@pub_year,'99')


Code Block
titleJson Response
collapsetrue
{
 "lang": "en", 
 "price": 895, 
 "title": "Feersum Endjinn", 
 "authors": [
            "Iain M. Banks"
 ], 
"pub_year":1994
}  
{
 "lang": "en", 
 "price": 699, 
 "title": "The Golden Compass", 
 "authors": [
           "Philip Pullman"
 ], 
"pub_year":1995
}            

                                                                                                    
                                                                                       

...

_ : Matches any single character.

#

Query

Output

1

cpsdb=# SELECT * FROM FRAGMENT WHERE anchor_id = 4 and attributes->>'lang' like '%en%';



Code Block
titleJson Response
collapsetrue
{
 "lang": "en", 
 "price": 699, 
 "title": "The Golden Compass", 
 "authors": [
           "Philip Pullman"
 ], 
"pub_year":1995
}                                                                                                
{
 "lang": "english", 
 "price": 895, 
 "title": "Feersum Endjinn", 
 "authors": [
            "Iain M. Banks"
 ], 
"pub_year":1994
}    
            
2cpsdb=# SELECT * FROM FRAGMENT WHERE anchor_id = 4 and attributes->>'lang' ilike '%En%';


Code Block
titleJson Response
collapsetrue
{
 "lang": "en", 
 "price": 699, 
 "title": "The Golden Compass", 
 "authors": [
           "Philip Pullman"
 ], 
"pub_year":1995
}                                                                                                
{
 "lang": "English", 
 "price": 895, 
 "title": "Feersum Endjinn", 
 "authors": [
            "Iain M. Banks"
 ], 
"pub_year":1994
}              


3cpsdb=# SELECT * FROM FRAGMENT WHERE anchor_id = 4 and attributes->>'lang' like 'en';


Code Block
titleJson Response
collapsetrue
{
 "lang": "en", 
 "price": 699, 
 "title": "The Golden Compass", 
 "authors": [
           "Philip Pullman"
 ], 
"pub_year":1995
}           


2.Using SIMILAR TO Regular Expression Keyword :

The only difference between like and similar to is to pattern matches the given string. It is similar to LIKE, except that it interprets the pattern using the SQL standard's definition of a regular expression

SIMILAR TO supports these pattern-matching metacharacters borrowed from POSIX regular expressions:

  • | denotes alternation (either of two alternatives).

  • * denotes repetition of the previous item zero or more times.

  • + denotes repetition of the previous item one or more times.

  • ? denotes repetition of the previous item zero or one time.

  • {m} denotes repetition of the previous item exactly m times.

  • {m,} denotes repetition of the previous item m or more times.

  • {m,n} denotes repetition of the previous item at least m and not more than n times.

  • Parentheses () can be used to group items into a single logical item.

  • A bracket expression [...] specifies a character class, just as in POSIX regular expressions.

...

1.Update antlr parser to recognize this pattern
2.Implement required (native) query
3.Add db-container Integration tests for
     a.filter on string leaf-value
     b.filter on Integer leaf-value
     c.filter on leaf-list value
4.Update documentation
5.demo to team 


Limitations

1. contains condition is case sensitive.
2. Only leaves can be used, leaf-list are not supported.
3. Only string and integer values are supported, boolean and float values are not supported.
4. When empty value is passed with contains it returns all the nodes that has given leaf element.