Search groups and field filters

Introduction

Search groups are the core of Faceted Search when configuring indexed views. In table tsSearchGroups the basic settings of the indexed views can be configured.

Textual content often is surrounded by html tags, vipers and other programmabilities. Most of the time (typically on front-ends) it is undesirable to present this logic data. In order to correctly present the data used in indexed views, field filters can be used, which are stored in table tsFieldFilters.

More information about tables tsSearchGroups and tsFieldFilters can be found in this item.

Search groups

In the Smartsite manager user action Search Groups can be found in the Faceted Search Console under Tools after successfully installing Faceted Search. As a default this is filled with three search groups:

• PUB is a default Front-End search group, typically used for front-end purposes
• CMS is a default Back-End search group, typically used for back-end authors
• SXML is a default Developers search group, typically used for back-end developers

Besides Code and Name of the search group, note that it is a good practice to also define the LocaleId of the search group, which initially is set to the default SQL Server locale, which probably is US English.

Not properly setting the LocaleId matching to the actual language used in the content may result to incorrect or incomplete search results. Especially in SQL Server 2008 when a field is Full Text indexed in English while searching in Dutch this may lead to undesirable search results. Therefore, it is recommended to actively set the search group LocaleId which Full Text indexes the content in a specific language while not specifying a language in the search query. This search query defaults to searching in the language which was used during Full Text indexing.

The name of the database view should be chosen wisely and consistently. It is recommended to prefix this name with vwts, meaning an indexed view dynamically built by Faceted Search. Note that an indexed view's behavior more resembles to a physical table rather than an ordinary view. Actually, an ordinary view will be considered a literal replacement of its view definition by both SQL Server as Oracle database technologies. In contrast, an indexed view (or materialized view in Oracle's terms) will be treated as a physical view, thus boosting the performance of search queries. This performance boost is extremely important for Faceted Search since these views contain several User Defined Functions (UDFs), string concatenations and dependencies of e.g. content type.

Note that using search groups to separate multilingual content is a good practice. To do so, simply define search groups with view names like vwtsContentPUB_Dutch and vwtsContentPUB_USEnglish, specifying proper localeid accordingly and manage Faceted Search configuration xmls in order to use the correct view (language).

It is highly recommended to leave Use Full-Text checked since this will make sure the indexed view will be indexed by the Full Text Catalog. Please refer to this page and beyond for more information of the FTS and iFTS technologies.

Typically for front-end's purposes the Use Searchable flag is checked, while unchecked for all other types of search groups like back-end editorial or back-end developer's search groups. This simply states that individual items of which the Searchable bit is set to False, this particular item will be excluded from the search group, thus can never be found by the search group. It is not recommended to use this feature for security purposes rather than simply to ignore irrelevant pages like login pages etc.

The Fulltext Stoplist only has effect when using SQL Server 2008. Here, the desired stoplist can be managed for each search group. Choosing OFF simply disable usage of a stoplist for this search group while choosing SYSTEM uses the system stoplist. Note that it does not make sence to use SYSTEM while it is possible to create a custom stoplist prefilled with the system stoplist. System stoplists can not be modified in contrast to custom stoplists. More on stoplists can be found on this page and this page.

Field filters

In the Smartsite manager user action Field Filters can be found in the Faceted Search Console under Tools after successfully installing Faceted Search. As a default this is filled with three search groups:

• plaintext strips textual contents of HTML tags and vipers, while converting numeric entities to Unicode storage (nvarchar)
• novipers strips only vipers from textual contents and converting numeric entities to Unicode storage
• rawtext only converts textual contents numeric entities to Unicode storage
• raw does not do anything with the field which typically is only desirable for binary content

Basically, a field filter is used to apply database logic to a field when it's added to a Faceted Search database view. These field filters should then be used within the SearchGroups content type field property, e.g. PUB(plaintext), SXML(raw).

The replacement value is used as a substitute of the field name when generating the indexed view for Faceted Search. Use {FIELD} as fieldname placeholder.

Linked Data Search Groups (LinkedDataSearchGroups)

It is possible to include items of ContentType File Link (FLK; references files on disk) in Search Groups. In order to do so, CTFP LinkedDataSearchGroups should be set on the Nr field of ContentType FLK. The value of this CTFP resembles that of CTFP SearchGroups (e.q. PUB(RAW),CMS(RAW),SXML(RAW)). Smartsite will index the binary content stored in the field CTSpecificVarbinary1. Note that this field is not editable in Smartsite for ContentType FLK, which is logical because formally an item of this ContentType is merely a reference. Hence, CTFP LinkedDataSearchGroups must be set on Nr instead of any other field.