Package com.atlassian.jira.search.issue.index.indexers

Interface FieldIndexer

All Known Subinterfaces:
CustomFieldIndexer, FieldWithVisibilityIndexer
All Known Implementing Classes:
AffectedVersionsIndexer, AssigneeIndexer, AttachmentIndexer, BaseCustomFieldIndexer, BaseLabelsIndexer, CascadingSelectCustomFieldIndexer, ComponentsIndexer, CreatedDateIndexer, CreatorIndexer, CurrentEstimateIndexer, CustomFieldIndexerWithStats, CustomFieldLabelsIndexer, DateCustomFieldIndexer, DescriptionIndexer, DueDateIndexer, EnvironmentIndexer, ExactTextCustomFieldIndexer, FieldIndexerWithStats, FixForVersionsIndexer, GroupCustomFieldIndexer, IssueIdIndexer, IssueKeyIndexer, IssueLinkIndexer, IssueTypeIndexer, LabelsCustomFieldIndexer, LabelsIndexer, LocalDateIndexer, MultiGroupCustomFieldIndexer, MultiUserCustomFieldIndexer, NumberCustomFieldIndexer, OriginalEstimateIndexer, ParentIssueIndexer, PriorityIndexer, ProgressIndexer, ProjectCustomFieldIndexer, ProjectIdIndexer, ReporterIndexer, ResolutionDateIndexer, ResolutionIndexer, SecurityIndexer, SelectCustomFieldIndexer, SlowFieldIndexer, SortableTextCustomFieldIndexer, StatusIndexer, SubTaskIndexer, SummaryIndexer, TimeSpentIndexer, UpdatedDateIndexer, UserCustomFieldIndexer, VersionCustomFieldIndexer, VisibilityBaseFieldIndexer, VoterIndexer, VotesIndexer, WatcherIndexer, WatchesIndexer, WorkRatioIndexer
@PublicSpi public interface FieldIndexer
This is meant to create a portion of a FieldValue that is relevant for a Jira field.

The portion that is added to the collector will be the indexed value that is represented by the value contained in the Issue object when the indexFields(FieldValueCollector, Issue, CustomFieldPrefetchedData) method is called.

There is a strong relationship between a FieldIndexer and a ClauseQueryMapper as the indexer declares index fields and the query factory assumes it knows how to generate a query that will find relevant issues based on the values that were indexed.

If you are writing a CustomFieldSearcher then the glue that binds the FieldIndexer and the ClauseQueryFactory together is the CustomFieldSearcher since it provides both the ClauseHandler and the FieldIndexer. Keep in mind that if you are creating one of these that the Indexer must declare fields that the ClauseQueryFactory knows how to search.

Since:
10.4

  • Field Details

  • Method Details

    • getId

      String getId()
      Returns:
      the String representation of the field id that this indexer is indexing, this must be unique for each independent FieldIndexer. If the Indexer does not represent a System or Custom field in Jira this should still return a unique string that describes the indexer.

    • getFields

      Collection<Field> getFields()
      Declares the fields to be added to the index schema

    • indexFields

      void indexFields(FieldValueCollector collector, Issue issue, CustomFieldPrefetchedData prefetchedData)
      This method allows an indexer the opportunity to add values to the provided collector that are relevant for searching and storage of the portion of the issue that the FieldIndexer handles.

      If, for example, the indexer handles indexing an issues summary then this indexer will add a field value to the collector that represents the stored and searchable summary of the issue.

      Note that trying to index very large (i.e. larger than ~32 kB) fields as KeywordField will result in them being removed to prevent the indexing operation from crashing. This is a limitation of how OpenSearch and Lucene store terms.

      Parameters:
      collector - the collector for collecting indexed values
      issue - the issue that contains the data that will be indexed and which can be used to determine the project/issue type context that will allow you to determine if we should add the value as searchable or unsearchable.
      prefetchedData - if the custom field type implemented CustomFieldType.getNonNullCustomFieldProvider() this reference will hold the matching value returned from NonNullCustomFieldProvider.getCustomFieldInfo(List <Issue>)

    • isFieldVisibleAndInScope

      boolean isFieldVisibleAndInScope(Issue issue)
      This method is used to determine if the indexer is relevant for the provided issue. This method must check the fields visibility, in relation to the field configuration scheme, must check any global flags that would enable or disable a field (such as enable votes flag), and must check, if the field is a custom field, if the custom field is relevant for this issue.

      All these checks should take into account the IssueContext as defined by the passed in issue.

      The result of this method is used to determine the correct values that should be returned when performing an empty search.

      Parameters:
      issue - that is having a document created from.
      Returns:
      if true then this field is relevant for the issue, otherwise it is not.

    • indexFieldsWithVisibility

      default void indexFieldsWithVisibility(FieldValueCollector collector, Issue issue, CustomFieldPrefetchedData prefetchedData, boolean visible)
      The same as indexField but accepts an additional parameter to indicate if the field is visible and in scope. Thanks to that there is no need to call isFieldVisibleAndInScope(Issue) method inside. The default implementation is for backward compatibility. An indexer that wants to take advantage of performance gain should implement FieldWithVisibilityIndexer interface
      Parameters:
      collector - the collector for collecting indexed values
      issue - that is having a document created from.
      prefetchedData - if the custom field type implemented CustomFieldType.getNonNullCustomFieldProvider() this reference will hold the matching value returned from NonNullCustomFieldProvider.getCustomFieldInfo(List <Issue>)*

    • skipsIndexingNull

      @ExperimentalApi default boolean skipsIndexingNull()
      Used to declare how the indexer handles nulls.
      Returns:
      true if the indexer doesn't do anything when the field value is null