General

  eZ Systems Website
  Editor documentation


  Developer documentation

  Back to the top

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Introduction

Available Search Engines

Currently 3 search engines exists on their own eZ Platform Bundles:

  1. Legacy, a database-powered search engines for basic needs.
  2. Solr, an integration providing better overall performance, much better scalability and support for more advance search capabilities RECOMMENDED
  3. ElasticSearch, similar to Solr integration, however currently not under active development EXPERIMENTAL, NOT SUPPORTED

 

 

Usage

Search Criteria and Sort Clauses

Search Criteria  and Sort Clauses are value object classes used for building Search Query, to define filter criteria and ordering of the result set. eZ Platform provides a number of standard Criteria and Sort Clauses that you can use out of the box and that should cover the majority of use cases.

Example of standard ContentId criterion

Search Engine Handling of Search Criteria and Sort Clauses

As Search Criteria and Sort Clauses are value objects which are used to define the Query from API perspective, they are are common for all storage engines. Each storage engine needs to implement its own handler for corresponding Criterion and Sort Clause value object, which will be used to translate the value object into storage specific search query.

Example of ContentId criterion handler in Legacy Storage Engine
Example of ContentId criterion handler in Solr Storage engine

Custom Criteria and Sort Clauses

Sometimes you will find that standard Search Criteria and Sort Clauses provided with eZ Publish are not sufficient for you needs. Most often this will be the case if you have developed a custom Field Type using external storage, which therefore can not be searched using standard Field Criterion.

On use of Field Criterion/SortClause with large databases

Field Criterion/SortClause does not perform well by design when using SQL database, so if you have a large database and want to use them you either need to use Solr search engine, or develop your own Custom Criterion / Sort Clause to avoid use of attributes (Fields) database table, and instead uses a custom simplified table which can handle the amount of data you have.

In this case you can implement a custom Criterion or Sort Clause, together with the corresponding handlers for the storage engine you are using.

Difference between Content and Location Search

These are two basic types of searches, you can either search for Locations or for Content. Each has dedicated methods in Search Service:

Type of searchMethod in Search Service
ContentfindContent()
ContentfindSingle()
LocationfindLocations()

All Criteria and Sort Clauses will be accepted with Location Search, but not all of them can be used with Content Search. Reason for this is that while one Location always has exactly one Content item, one Content item can have multiple Locations. In this context some Criteria and Sort Clauses would produce ambiguous queries and such will therefore not be accepted by Content Search.

Content Search will explicitly refuse to accept Criteria and Sort Clauses implementing these abstract classes:

  • eZ\Publish\API\Repository\Values\Content\Query\Criterion\Location
  • eZ\Publish\API\Repository\Values\Content\SortClause\Criterion\Location

How to configure your own Criterion and Sort Clause Handlers

After you have implemented your Criterion / Sort Clause and its handler, you will need to configure the handler for the service container using dedicated service tags for each type of search. Doing so will automatically register it and handle your Criterion / Search Clause when it is given as a parameter to one of the Search Service methods.

Available tags for Criterion handlers in Legacy Storage Engine are:

  • ezpublish.search.legacy.gateway.criterion_handler.content
  • ezpublish.search.legacy.gateway.criterion_handler.location

Available tags for Sort Clause handlers in Legacy Storage Engine are:

  • ezpublish.search.legacy.gateway.sort_clause_handler.content
  • ezpublish.search.legacy.gateway.sort_clause_handler.location

You will find all the native handlers and the tags for the Legacy Storage Engine available in the eZ/Publish/Core/settings/storage_engines/legacy/search_query_handlers.yml file.

Example of registering ContentId Criterion handler, common for both Content and Location Search

Registering Criterion handler

Example of registering Depth Sort Clause handler for Location Search

Registering Sort Clause handler

See also

See also Symfony documentation about Service Container for passing parameters

 

Criteria Independence Example

With eZ Publish you can have multiple location content. Criterions do not relate to others criterion you can  use the Public API and Criterion to search this content, it can lead to a comportement you are not expecting.
Example of Criterions not relating to each other:
 
There is a Content with two Locations: Location A and Location B
  • Location A is visible
  • Location B is hidden
 
Searching with LocationId criterion with Location B id and Visibility criterion with Visibility::VISIBLE will return the Content because conditions are satisfied:
  • Content has Location B
  • Content is visible (it has Location A that is visible)
 

 

 

 

Reference

 

Search Criteria Reference

Criteria are the filters for Content and Location Search, for generic use of API Search see Search Criteria and Sort Clauses todelete.

A Criterion consist of two parts just like SortClause and FacetBuilder:

  • The API Value: Criterion
  • Specific handler per search engine: Criterion Handler

Criterion represents the value you use in the API, while CriterionHandler deals with the business logic in the background translating the value to something the Search engine can understand.

Implementation and availability of a handler typically depends on search engine capabilities and limitations, currently only Legacy (SQL) Search Engine exists, and for instance its support for FullText and Field Criterion is not optimal and it is advised to avoid heavy use of these until future search engine arrives.

Common concepts for most Criteria

For how to use each and every Criterion see the list below, as it depends on the Criterion Value constructor, but in general you should be aware of the following common concepts:

  • target: Exposed if the given Criterion supports targeting a specific sub field, example: FieldDefinition or Meta Data identifier
  • value: The value(s) to filter on, this is typically a  scalar or array of scalars.
  • operator: Exposed on some Criteria
    • All operators can be seen on eZ\Publish\API\Repository\Values\Content\Query\Criterion\Operator, at time of writing: IN, EQ, GT, GTE, LT, LTE, LIKE, BETWEEN, CONTAINS
    • Most Criteria do not expose this and select EQ or IN depending on if value is scalar or array
    • INBETWEEN always acts on an array of values, while the other operators act on single scalar value
  • valueData : Additional value data, required by some Criteria, MapLocationDistance for instance

 

In the Legacy search engine, the field index/sort key column is limited to 255 characters by design.
Due to this storage limitation, searching content using the eZ Country Field Type when there are multiple countries selected may not return all the expected results.


List of Criteria

The list below reflects Criteria available in the eZ\Publish\API\Repository\Values\Content\Query\Criterion namespace (it is also possible to make a custom Criterion):

Only for LocationSearch

CriterionConstructor arguments description
Location\Depthoperator (IN, EQ, GT, GTE, LT, LTE, BETWEEN), value being the Location depth(s) as an integer(s).
Location\IsMainLocationWhether or not the Location is a Main Location
value (Location\IsMainLocation::MAIN, Location\IsMainLocation::NOT_MAIN).
Location\PriorityPriorities are integers that can be used for sorting in ascending or descending order. What is higher or lower priority in relation to the priority number is left to the user choice.
operator (GT, GTE, LT, LTE, BETWEEN), value being the location priority(s) as an integer(s).

 

Common

CriterionConstructor arguments description
ContentId value being scalar(s) representing the Content id.
ContentTypeGroupIdvalue being scalar(s) representing the Content Typ eGroup id.
ContentTypeIdvalue being scalar(s) representing the Content Type id.
ContentTypeIdentifier value being string(s) representing the Content Type identifier, example: "article".
DateMetadata target (DateMetadata ::MODIFIED, DateMetadata ::CREATED), operator (IN, EQ, GT, GTE, LT, LTE, BETWEEN), value being integer(s) representing unix timestamp.
Field

target (FieldDefinition identifier), operator (IN, EQ, GT, GTE, LT, LTE, LIKE,  BETWEEN, CONTAINS), value being scalar(s) relevant for the field.

FieldRelation target (FieldDefinition identifier), operator (IN, CONTAINS), value being array of scalars representing Content id of relation.
Use of IN means relation needs to have one of the provided ID's, while CONTAINS implies it needs to have all provided id's.
FullText

value being the string to search for, properties is array to set additional properties for use with future search engines like Solr/ElasticSearch.

LanguageCodevalue being string(s) representing Language Code(s) on the Content (not on Fields), matchAlwaysAvailable as boolean.
LocationIdvalue being scalar(s) representing the Location id.
LocationRemoteIdvalue being string(s) representing the Location Remote id.
LogicalAndA LogicalOperator that takes array of other Criteria, makes sure all Criteria match.
LogicalNotA LogicalOperator that takes array of other Criteria, makes sure none of the Criteria match.
LogicalOrA LogicalOperator that takes array of other Criteria, makes sure one of the Criteria match.
MapLocationDistance target (FieldDefinition identifier), operator ( IN, EQ, GT, GTE, LT, LTE, BETWEEN), distance as float(s) from a position using latitude as float, longitude as float as arguments
MatchAllNo arguments, mainly for internal use when no filter or query is provided on Query object.
MatchNone No arguments, mainly for internal use by BlockingLimitation.
ObjectStateIdvalue being string(s) representing the Content ObjectState id.
ParentLocationId

value being scalar(s) representing the Parent's Location id

RemoteIdvalue being string(s) representing the Content Remote id.
SectionIdvalue being scalar(s) representing the Content Section id.
Subtreevalue being string(s) representing the Location id in which you can filter. If the Location Id is  /1/2/20/42, you will filter everything under 42.
UserMetadata target (UserMetadata ::OWNER , UserMetadata ::GROUP , UserMetadata ::MODIFIER), operator (IN, EQ ), value being scalars (s) representing the User or User Group id(s).
Visibility value (Visibility ::VISIBLE , Visibility ::HIDDEN), Note: This acts on all assigned locations when used with ContentSearch, meaning hidden content will be returned if it has a location which is visible. Use LocationSearch to avoid this.

 

 

Sort Clauses Reference

Sort Clauses are the sorting options for Content and Location Search in eZ Platform. For generic use of API Search see Search Criteria and Sort Clauses todelete.

A Sort Clause consists of two parts just like Criterion and FacetBuilder:

  • The API Value: SortClause
  • Specific handler per search engine: SortClausesHandler

The SortClause represents the value you use in the API, while SortClauseHandler deals with the business logic in the background, translating the value to something the Search engine can understand.

Implementation and availability of a handler sometimes depends on search engine capabilities and limitations.

Common concepts for all Sort Clauses 

For how to use each and every Sort Clause, see list below as it depends on the Sort Clause Value constructor, but in general you should be aware of the following common concept:

  • sortDirection: The direction to perform the sort, either Query::SORT_ASC (default) or Query:: SORT_DESC

List of Sort Clauses 

The list below reflects Sort Clauses available in the eZ\Publish\API\Repository\Values\Content\Query\SortClause namespace (it is also possible to make a custom Sort Clause):

Arguments starting with "?" are optional.

Only for LocationSearch

Sort ClauseConstructor arguments description
Location\Depth ?sortDirection
Location\Id ?sortDirection
Location\IsMainLocation ?sortDirection
Location\Depth ?sortDirection
Location\Priority ?sortDirection
Location\Visibility ?sortDirection

 

Common

Sort ClauseConstructor arguments description
ContentId?sortDirection
ContentName ?sortDirection
DateModified?sortDirection
DatePublished ?sortDirection
Field

typeIdentifier as string, fieldIdentifier as string, ?sortDirection, ?languageCode as string

MapLocationDistance  typeIdentifier as string , fieldIdentifier as string , latitude as float ,   longitude as float, ? sortDirection, ?languageCode as string
SectionIdentifier ?sortDirection
SectionName ?sortDirection

 

 

  • No labels