Skip to main content

​
Splitting Strategy

diagram

​
Predicate Classification

Predicate TypeExecution StageLucene-Compatible
Equality (eq)Lucene queryYes
Inequality (ne, !=)Lucene queryYes
Null checkLucene queryYes (via HAS_VALUE)
AND compositeLucene queryYes
OR compositeLucene queryYes
NOT (unary)Lucene queryYes
Object ID with project prefixLucene queryYes
Complex navigation predicatesPost-filterNo
Predicates on expanded propertiesPost-filterNo
Predicates that can be translated to Lucene execute at the database level, reducing the number of entities fetched from Polarion. Post-filter predicates require all candidate entities to be loaded first, then filtered in memory.

​
Query Execution Pipeline

The query processor follows this execution order:
  1. Predicate analysis — Classify each predicate as Lucene-compatible or post-filter
  2. Lucene query construction — Combine Lucene-compatible predicates with type and project constraints
  3. Database execution — Execute Lucene query against Polarion IDataService
  4. Post-filter application — Apply remaining predicates in memory on the result set
  5. Expansion path resolution — Load related entities via expansion paths
  6. Security enforcement — Verify entity-level read permissions

​
Document Query Optimization

When the where clause contains document-level predicates (e.g., filtering by document properties), the query processor extracts these predicates and pre-resolves matching documents before querying work items. This reduces the work item query scope by restricting it to items within specific documents.
StepActionResult
1Extract document predicates from where clauseDocument filter criteria
2Resolve matching documentsList of document IDs
3Add document.id constraint to work item queryScoped Lucene query
4Execute constrained work item queryReduced result set
The exact set of predicates classified as document-level depends on the query structure. Verify query execution plans using the explain query parameter when available.

​
Query Parameters

The query processor extracts parameters that control query behavior.
ParameterTypeDefaultDescription
revisionstringnullExecute query against a specific baseline revision
currentDocstringnullDocument ID filter for document-scoped queries
currentDocConstraintstringnullEntity type or expansion path for document scoping
explainbooleanfalseEnable debug output for query execution
See Query Context and Baseline and Revision Queries for parameter details.

​
Security Enforcement

Before any query executes, the processor verifies that the current user has read permission for the queried entity type. Queries against unauthorized entity types fail immediately without executing the Lucene query.
Entity-level security is checked before any query execution. If the current user does not have READABLE permission for the entity type, the query returns an error immediately.

​
Constraint Annotations

The query processor applies constraint annotations from the domain model to queries:
  • Project constraints from entity type annotations are merged into the Lucene query
  • Document constraints from entity type and expansion path annotations are merged into document filters
  • Navigation property constraints combine both the expansion path and target entity type constraints
See Constraints for domain model constraint configuration.

​
Complete YAML Example

sources:
  - id: requirements
    title: System Requirements
    model: rtm
    query:
      from: UserNeed
      where: "type:userNeed AND HAS_VALUE:title"
    constraints:
      applyCurrentDocumentTo: UserNeed
    expand:
      - name: systemRequirements
        title: System Requirements
        expand:
          - name: systemRequirement
            expand:
              - name: designRequirements
                expand:
                  - name: designRequirement
In this configuration:
  • The where clause contains Lucene-compatible predicates (type: and HAS_VALUE:)
  • The applyCurrentDocumentTo constraint restricts results to the current document context
  • Expansion paths load related entities after the primary query executes
Source context: PolarionQueryProcessor, GenericQueryResolver, QueryToLuceneTest, powersheet.yaml
Source Code
  • PolarionQueryProcessor.java
  • powersheet.yaml
  • GenericQueryResolver.java
  • prod-powersheet-src/com.nextedy.powersheet.client/src/modules/ModelProvider/ModelProvider.tsx
  • QueryDataTest.java