A Comparison Type determines how the Filter does its filtering.
A filter's Comparison Type is defined during the creation of the filter:
Creation of a filter
The Comparison Type of a filter can be edited in the The Details panel.
There are 22 different Comparison Types:
3.1 FreeText
This Comparison Type is unique. All Filters with a FreeText Comparison Type are gathered into a single filter with an ID of "freetext".
Example:
A search with a single free text filter:
And to keep it simple, the DAM Center, which I am using, only has one asset:
The title of the asset is "Hydrangeas".
Because the search only has one free text filter, the string, which the parameter is compared to, will be "Hydrangeas".
The asset has two keywords: "flower" and "summer", so if you were to add a Keywords free text filter, the string, which the parameter is compared to, will be "Hydrangeas flower summer", i.e. "Title Keyword Keyword".
The asset has a description of "pretty flower", so if you were to add a Description free text filter, the string, which the parameter is compared to, will be "Hydrangeas flower summer pretty flower", i.e. "Title Keyword Keyword Description".
The "comparison" is a Contains function, ie the filter will return any assets, whose "free text string" contains the parameter, e.g. a parameter of "flower" will return the asset. The parameter "flo" will not return the asset. However, the parameter "flo*" will return the asset.
Due to the inner workings of how such filters work, any search, which has a freetext filter, MUST be populated (see UseSolr for a guide on how to populate a search).
3.2 Equals
Tests whether a Filter's parameter matches exactly with the data, the filter works on.
Example:
This filter filters out any results, whose item ID does not match a supplied ID.
Accepts a single parameter.
3.3 EqualsWithZeroAsNull
The same as Equals, but treats a value of "null" as "0", where "0" is of data type bit, ie "1" equals "true" and "0" equals "false".
Accepts a single parameter.
3.4 EqualsOrNull
The same as with Equals except that results with a null value are not filtered out.
Accepts a single parameter.
3.5 AllInList
Filters out any items with data, which does not exactly match all the supplied parameters.
Example:
This filter will filter out any items, whose keywords does not contain the supplied keywords, i.e. if an asset has the keywords "pink", "fluffy", "Sith", and "Lord" and a user inputs "pink" and "kitten", then the "pink fluffy Sith lord" asset will be filtered out. If the user inputs "pink" and "fluffy" then the Sith lord will be returned.
Accepts 1-many parameters.
3.6 InList
Filters out any items with data, which does not exactly match any of the supplied parameters.
Example:
Using this filter, if a user inputs "pink" and "kitten", then in this case, the "pink fluffy sith lord" will not be filtered out because one of the asset's keywords is "pink".
Accepts 1-many parameters.
3.7 NotInList
Filters out any results, which does match any of the supplied parameters.
Example:
If a user inputs "pink" and "kitten" then the "pink fluffy sith lord" asset will be filtered out, because one of its keywords is "pink".
Accepts 1-many parameters.
3.8 Like
Works almost exactly like the SQL "like" operator.
The easiest way to understand the differences is with a brief example:
The filter:
If the user inputs a parameter with value "key", the final like statement is "like 'key%", ie any meta fields, which does not have a name starting with "key", are filtered out.
If the user inputs "*key*" or "*key", the like statement becomes "like %key%".
A Like filter is very expensive, so be wary using this Comparison Type, as it may result in very slow searches.
3.9 Between
"Between" is a very specific Comparison Type: it can only be used with filters, which does work on dates or DateTimes, e.g. "asset.start_date" and "asset.end_date".
If a similar functionality is needed, but in the context of data other than dates or DateTimes, e.g. filtering out results whose IDs are between 5 and 11, that functionality MUST be mimicked by creating two filters. An example of such two filters can be two filters with respective Comparison Types of GreaterThan with a parameter value of 11 and LessThan, with a parameter value of 5:
3.10 GreaterThan
Filters out any results whose data is not greater than the supplied parameter, i.e. it works exactly like the ">" operator.
3.11 LessThan
Filters out any results whose data is not less than the supplied parameter, i.e. it works exactly like the "<" operator.
3.12 EqualsOrGreaterThan
Filters out any results whose data is not equal to or greater than the supplied parameter, i.e. it works exactly like the ">=" operator.
3.13 EqualsOrLessThan
Filters out any results whose data is not equal to or less than the supplied parameter, i.e. it works exactly like the "<=" operator.
3.14 RecursiveLayoutfolder
Works exlusively with folders located in the table layoutfolders. As such, this Comparison Type will NOT work with other data.
Filters out assets, which do not belong to a folder, which is a child of the folder with the supplied layout folder ID parameter.
3.15 RecursiveDamcatalogfolder
Works exactly like RecusiveLayoutfolder, except that it looks at the folders defined in damcatalog_folder.
3.16 IsDescendantOf
Works exclusively with data, which is an SQL hierarchy ID. Filters out any results which are not descendants.
3.17 Empty
Filters out results, whose data is or an empty string.
3.18 NotEmpty
Filters out results, whose data is not null or an empty string.
3.19 EmptyCheckField
The same as Empty, except that this filter will not be applied, if the user does not supply a parameter.
3.20 NotEmptyCheckField
The same as NotEmpty, except that this filter will not be applied, if the user does not supply a parameter.