The Perfion Query - WHERE
The Where part is built up from a list of clauses that are AND’ed together in the following manner:
XML:
<Where>
<Clause id='Category.ID' operator='=' value='3' />
<Clause id='NoOfCups' operator='=' value='6' />
<Clause id='PowerW' operator='BETWEEN'>
<Value>100</Value>
<Value>300</Value>
</Clause>
</Where>
JSON:
"Where": {
"Clauses": [
{ "Clause": { "id": "Category.ID", "operator": "=", "value": "3" } }
{ "Clause": { "id": "NoOfCups", "operator": "=", "value": "6" } }
{ "Clause": { "id": "PowerW", "operator": "BETWEEN", "value": [ "100", "300" ] } }
]
}
Features
Each feature can be written as either the unique featurename or the unique featureID. It is possible to change the feature name in Perfion so the featureID is more safe to use, but using the name makes it considerably easier to read and write the queries.
When more features are written after one another, they refer to the values of features on features such as e.g. Actor.Age>35.
When no features are written the clause refers to the type of items being returned, i.e. the FROM features e.g. the Product name. In this case a Property must be specified e.g. String='1923-18'
Wildcard features
Instead of naming a single feature explicitly to search for the same value across several features by using a wildcard instead of the feature name, such as:
*.Number>100 (In case the retrieved Items are Products , this would mean any feature on Products that has a numeric value greater than 100, but it could also be written as Material.*.Number>100 (meaning any products from Manufacturers that have any numeric feature with values greater than 100).
Instead of using wildcards, it is also possible to specify exactly which features to search, e.g.
(105,200,265).Number>100 (meaning any Products that have a numeric value greater than 100, on the features with ID 105, 200 or 265. For this special notation the feature ID values must be used, the feature names are not supported.
Properties
For a feature such as Actor, its datatype would most likely be defined as a string whereas a feature such as Age would be a Number. By writing the feature Actor it would then be interpreted as a string value and Age as a Number value. However, for all features it is possible to explicitly access the following properties:
String, Number, Text, Date, BinaryID
In many cases it is irrelevant to write which property to use since it is derived automatically from the feature, e.g. writing; Actor='Gibson' or Actor.String='Gibson' has the same meaning since the feature Actor is defined as datatype string. For the feature Actor it does not make sense to access any of the other properties since they give no meaning.
For some features it does give meaning to access the properties directly. When working with images or files they consist of both the binary file and a file name. In these cases these values can be accessed as Image.String='filename.jpg' and Image.BinaryID='<Guid>' where the Guid is the unique identity used to reference the binary file.
StringText
The StringText property combines the String and Text properties for searching purposes, and is mostly relevant when doing Feature Wildcard searches across multiple features such as e.g.
*.StringText LIKE '%ST%'
This would find any Product that contains the value Audi on any feature irregardless of whether it is a String or Text feature.
ModifiedBy, ModifiedDate, CreatedBy, CreatedDate
These properties would f.x. make it possible to find all products that have values modified since a specific date. The ModifiedBy and ModiFiedDate properties can be applied anywhere.
The CreatedBy and CreatedDate Properties can be applied anywhere, with the exception that they cannot follow non-selectable features such as e.g. ItemNumber.CreatedBy='Admin'. In this case simply write: CreatedBy='Admin' which would yield all Items that were created by the specified user.
ModifiedDate can be used to find both all items modified at some point or items where some spec is modified at some point. Consider the following examples:
<Clause id="ModifiedDate" operator="BETWEEN">
<Value>2020-01-03 10:00:00</Value>
<Value>2020-01-03 11:00:00</Value>
</Clause>
The above clause will match any item modified between 10:00 and 11:00, January 3rd in 2020. And by modified it means that any feature value (Spec) has been either inserted/updated/deleted.
The above clause will find all items on which their ItemNumber has either been updated or inserted between 10:00 and 11:00. Notice that it will not find items in which their ItemNumber has been deleted.
For a selectable feature, say Color, the query must be written slightly different:
Notice the extra colon in between Color and ModifiedDate. The above will find items that either have some Color updated or inserted. It could be a product that where once color “Red” was picked but now has been changed to instead point to “Red”.
If you want to find all items in which their selectable values have changed. Not the link as above, but rather the Item (here the Color pointed to), you would write:
As can be seen here the colon simply is removed. This will find all Items in which their Colors pointed to have changed. And by changed it means the item or any spec on it has changed.
Typically you would combine the two, i.e. you will select all items where Color has been changed regardless of where the change happened (the item or the item referred to). This is done like this:
Finally you can select all items upon which any feature has changed (i.e. been updated or inserted, but not deleted). This is done using a star (*) instead of a feature name like this:
Please note, that when it comes to remote features Perfion has no knowledge of when they were created and modified.
ID, ParentID, Brand
For Selectable features that have their own identities and can be attributed with other features themselves, the following extra identity properties are available:
This makes it possible to query against the ID of the actual items as well as their ParentID, which will probably be the preferred approach for programmatic control e.g. for web sites or other solutions, since data resultsets will always include the ID and ParentID of all items.
ParentID=0 (will only return Items in the root, i.e. they have no parents)
Furthermore it is also possible to specify which types of Items (e.g. Normal, Virtual, CatalogRoot or Branded ) to include in the query in the following manner:
Brand='Normal' (will only return normal items)
Languages
Using languages in clauses are always optional, and can only be relevant for localizable features. The default behavior is to search for a value in any language. If the query should only take values from 1 or more languages into account it is possible to do this by including the language codes as in the following example:
Color(EN,DE) LIKE 'Bl%'
This example will match all values from English and German language with Color values that starts with ‘Bl’ in their name such as Blue or Blau.
Operators
The Perfion query syntax offers the following operators.
= |
!= |
> |
>= |
< |
<= |
LIKE, NOT LIKE |
MATCH, NOT MATCH |
IN, NOT IN |
BETWEEN |
HAS, NOT HAS |
EXECUTE |
ISINVALID |
The operators will be described with examples below.
LIKE, NOT LIKE, =, !=, <, >, <=, >=
These operators are well known from normal SQL syntax and behave the same. The syntax for writing the Perfion clause looks like the following example:
XML:
JSON:
The LIKE operator behaves exactly like the well known LIKE operator from normal SQL syntax, with the possibility of using % for Wildcard searches.
MATCH, NOT MATCH
The MATCH operator is similar to the LIKE operator in that it can be used to perform wildcard searches. The primary difference between the 2 are, that normal users do not easily understand the LIKE behavior with explicit use of % as wildcard, but assumes that it is possible to just type a part of a word, or multiple words, and get some results.
Therefore, the MATCH operator automatically surrounds the search value with % wildcards (invisible to the user). But the MATCH operator goes even further, to split up multiple words into multiple clauses. The following table illustrates various searches and how they are interpreted:
MATCH | Interpretation |
Coffee | Contains Coffee (somewhere in the feature value) |
Black Coffee | Contains both Black and Coffee (somewhere in the feature value) |
“Black Coffee” | Contains “Black Coffee” (somewhere in the feature value) |