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 is used in this example, 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, i.e. 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.