Each object can have one or more (optional) indexes.

These are not part of the data model ‘per se’ – i.e. their presence does not define in any way the structure of the data stored in the database – but they tell the system which objects’ attribute will be used for searches and allow an improvement in performances.

The indexes can be either normal database indexes or full-text indexes (if supported by the underlying database server).

Improvements in 2.0

GN4-1246: When specifying indexes in the schema it is now possible to use also the 'built-in' columns that do not correspond to an attribute. In such cases use directly the name of the column instead than the name of the attribute - the valid column names are \gn_ParentId (within list and multi-reference attributes), gn_ChildId (within multi-reference attributes), gn_Order (within ordered list and multi-reference attributes) and s_id (within the main object declarations).

For example to create an index on pageRef and the parent object id for the list attribute linkObject.pageLayers use:

<xs:complexType name="linkObject">

<xs:complexContent>

<xs:extension base="folderObject">

<xs:sequence>

. . .

<xs:element name="pageLayers" minOccurs="0" gs:compute="true">

<xs:complexType>

<xs:sequence>

<xs:element name="item" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:annotation>

<xs:appinfo>

. . .

<gs:index attrs="pageRef gn_ParentId"/>

</xs:appinfo>

</xs:annotation>

<xs:sequence>

. . .

<xs:element name="pageRef" type="reference" minOccurs="0" gs:refer="page">

. . . .

Note that this specific index has already been added to the standard schemas.

 

See also

Defining indexes