Search Domain

Search Domains is used in order to find a business object using free text search. This is done by creating a model of type Searchdomain. The Search Domain model describes a business object in a tree structured way, meaning that you can have several entities involved in one Search Domain. On each entity in the Search Domain structure you define which attributes that should be indexed.

Each Search Domain consists of several database objects that are created automatically during enabling of a Search Domain. These database objects are:

• One package used for indexing and runtime properties

• One OracleText index

• Triggers for catching changes in columns included in the Search Domain

• Three background jobs for maintaining the OracleText index.

OracleText is used to implement free text search for Search Domains.

Search Domains can't be layered, meaning that they can't be extended.

Contents

• Text_Id$ column
• Design considerations
• LOB considerations
• Modeling
• Example
• Developer Studio References

Text_Id$ column

Each Search domain requires a specific column called Text_Id$ on the main table for the Search Domain. This column is required since an Oracle Text index must be related to a column with a unique key. In order to get an unique key these columns has a GUID as the column value. If a table has two Search Domains it requires two Text_Id$ columns. The Text_Id$ columns is modeled in the entity model.

Design considerations

A Search Domain is used to quickly and easily find data. It is not used to do "reporting" such as "find all orders for this particular customer created in February".

• Search Domain size
  Size matters. The more attributes included in your search domain, the more expensive to create and synchronize the index. Simple attributes in your main object doesn't have a very big impact but aggregates and references do. Thus, if you define a large search domain object structure, indexing will take time. Search domain size will also have a big performance impact on generating the "snippet" texts (the short summary text on a search hit).
• Including LOB attributes
  LOB columns are considerably more expensive to read than "ordinary" columns, thus, including LOB attributes will affect indexing performance.
• Keeping the Search Domain index up to date
  There are three Scheduled Tasks created to keep the index up to date - Synchronize, Optimize and Rebuild. Synchronization is relatively cheap since it will only process data that has been modified, added or deleted since the index was last updated. Rebuilding the index is very expensive since all the data will be indexed from scratch. The Search Domain should be designed in such way so the index don't need to rebuild too often. Optimizing the index removes old data and minimizes index fragmentation.

LOB considerations

Since it is not possible to catch changes in LOB attributes when a trigger is fired (no support for LOB's in triggers) the un-synchronization must be handled in the business logic. The business logic will always call a method called "Write-something" to update the LOB column and in that method the document needs to manually be marked as un-synched.
The following is an example of code if the LOB was on the master entity FndUser in the Search domain:

If the LOB attribute is located on an aggregate you must find the value of the indexed column (text_id$). In the generated PL/SQL package for the Search Domain you can find methods helping you to get the value of the indexed column. The example below is if a LOB was on the aggregate FndUserProperty:

Modeling

Read Model Syntax for Searchdomain how to model a search domain. At code generation, database objects files will be created based on the model.

Example

This example shows a Search Domain for Users. The main entity is FndUser and it has relations to FndUserProperty, UserGroupUsers and UserGroup. You can see that they are structured in a tree structure.

Developer Studio References

• Model Syntax for Searchdomain
• Keyword Overview
• Code Generation Properties