Migration to search version 2¶

New in version 25.2.

This page describes options for migrating a system from search version 1 to search version 2.

Important

Search version 2 still is in beta phase.

New configuration property¶

To migrate to another search version, a new configuration property has been added, to switch between the two versions of the index, called searchIndexSettings, see Search and indexing. This property decides which index model is in use and which index is to use for internal searches. Direct searches can be made via the correct API-endpoints.

Note

The index, which is not configured with this property, will be ignored for all reindex requests. A manual reindex request will also fail.
If you change this property to another index model, you have to perform a reindex.
Some features of the first search version are not supported in the second search. To see how the same results can be recieved with the new search, see Search version 2 (beta).

Usage of both indices at the same time¶

It is possible to keep both indices in usage at the same time. The property searchIndexSettings has to be set to either NewAndOld_UsingOldSearch or NewAndOld_UsingNewSearch, so both indices will be indexed. The reindex for the chosen indices happens automatically for adding, updating or removing metadata for all indexed entities. To trigger a manual reindex, it is necessary to specify the kind of document, which should be indexed (item, collection,shape ...) and which index model you use (old index version = PARENT_CHILD or new index version = NESTED). This manual reindex will trigger an index, for all chosen entities, see Re-indexing metadata.

Note

If any other value of this property is used, only one index is used in all index-processes.
For internal searches, it has to be decided which index model is to use. If the older index model is used for internal searches, but the direct search is performed with the search2 API-resources, the result might be compromised.
If both indices must be up to date, the property must not be OnlyNew or OnlyOld.

Both searches¶

It is still possible to use both searches directly.

The first and older search model can be reached with the already existing API-endpoints, see Search version 1. For the new search model, new API-calls have been implemented, see Search version 2.

To ensure a smooth change between the two search versions, the property searchIndexSettings must be set to at least NewAndOld_UsingOldSearch or NewAndOld_UsingNewSearch. Those properties ensure both indices with one of both search versions.

Libraries¶

To migrate to the second search model, it is necessary to recreate all libraries. It is not possible to transfer the existing libraries for to the new search, due to changes in the library creation process for the older search version. To recreate and use the libraries, please use the existing API, see Libraries.

Difference between both searches¶

This chapter explains the main differences between both searches.

The search version 2 now automatically filters all filterable input. The actual search is now smaller and faster.
The index in search version 2 has one document per item or collection. The index in search version 1 has one document per timespan. This way the index for the search version 2 is smaller and the performance is increased.
Events like concrete timespans or direct event or group search is now more efficient and more detailed.

The search version 2 can only be used via the new API-endpoints Search version 2.

It is necessary to sort search criteria in the generic elements (field, operator) and timed elements (timespans).
These API calls only work for searching in the index. For all other operation, please look into the correct API references.

Interval¶

The interval element of the ItemSearchDocument is not used anymore for the search version 2. To achieve the same results, it is necessary to sort all search related fields in the correct element of the SearchDocument.

Interval = all can be achieved, if the search is performed with the field or operator AND the timespans elements of the SearchDocument.

Interval = generic can be achieved, if the search is performed with the timespans element of the SearchDocument.

Interval = timed can be achieved, if the search is performed with the field or operator elements of the SearchDocument.

Filter¶

The SearchDocument has no direct filter value. In the search version 2, it is enough to search with as a simple field, to receive the correct result. Search version 2 automatically filters for values, which are fitting for filtering e.g. keywords, integer or boolean. Following examples produce the same result:

search version 1:

<ItemSearchDocument xmlns="http://xml.vidispine.com/schema/vidispine">
   <filter operation="OR" name="productType">
     <field>
       <name>type</name>
       <value>pc</value>
     </field>
     <field>
       <name>type</name>
       <value>phone</value>
     </field>
   </filter>
</ItemSearchDocument>

search version 2:

<SearchDocument xmlns="http://xml.vidispine.com/schema/vidispine">
    <field>
        <name>type</name>
        <value>pc</value>
        <value>phone</value>
    </field>
</SearchDocument>

Groups¶

The search element group, of the ItemSearchDocument, is not used in the search version 2. If a group is to use in version 2, it has to be searched with all subgroups and fields as on single field. If a search is performed with only the group name, but not with the field name, the search will fail.

<SearchDocument xmlns="http://xml.vidispine.com/schema/vidispine">
    <field>
        <name>Group/subgroup/field_name</name>
        <value>example</value>
    </field>
    <field>
        <name>Group/subgroup/another_field_name</name>
        <value>example</value>
    </field>
    <field>
        <name>Group/another_subgroup/field_name</name>
        <value>example</value>
    </field>
</SearchDocument>

MetadataGroups¶

The direct search for only metadata groups is not supported directly anymore for the search version 2. To receive the same results a search containing highlighting and text or field search has to be performed. Let’s say a group called V3_Football is searched with the value in the text search, the highlighting fields have to contain all subgroups and fields of this group to determine, which field (and if fitting which timespan) contains this value.

Note

You have to specify each group with the field. The highlighting will be performed on those exact field. Any other field might not be highlighted.

<SearchDocument>
    <field>
        <name>V3_Football/V3_Stadion</name>
        <value>cologne</value>
    </field
    <text>play</text>
    <highlight>
        <prefix><em></prefix>
        <suffix></em></suffix>
        <field>V3_Football/V3_Player</field>
        <field>V3_Football/V3_Stadion</field>
        <highlightTimespans>true</highlightTimespans>
    </highlight>
</SearchDocument>