Query Splitting - Nextedy Documentation

Splitting Strategy

Predicate Classification

Predicate Type	Execution Stage	Lucene-Compatible
Equality (`eq`)	Lucene query	Yes
Inequality (`ne`, `!=`)	Lucene query	Yes
AND composite	Lucene query	Yes
OR composite	Lucene query	Yes
NOT (unary)	Lucene query	Yes
Object ID with project prefix	Lucene query	Yes
Complex navigation predicates	Post-filter	No
Predicates on expanded properties	Post-filter	No

Null check predicates (for example, HAS_VALUE in Lucene syntax) are not currently functional in Powersheet query splitting. Do not rely on null-check predicates in where clauses until this is restored — use alternative filtering strategies such as explicit value matches or post-filter logic.

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:

Predicate analysis — Classify each predicate as Lucene-compatible or post-filter
Lucene query construction — Combine Lucene-compatible predicates with type and project constraints
Database execution — Execute Lucene query against Polarion IDataService
Post-filter application — Apply remaining predicates in memory on the result set
Expansion path resolution — Load related entities via expansion paths
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.

Step	Action	Result
1	Extract document predicates from `where` clause	Document filter criteria
2	Resolve matching documents	List of document IDs
3	Add `document.id` constraint to work item query	Scoped Lucene query
4	Execute constrained work item query	Reduced 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.

Parameter	Type	Default	Description
`revision`	`string`	`null`	Execute query against a specific baseline revision
`currentDoc`	`string`	`null`	Document ID filter for document-scoped queries
`currentDocConstraint`	`string`	`null`	Entity type or expansion path for document scoping
`explain`	`boolean`	`false`	Enable 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 data 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 data model constraint configuration.

Complete YAML Example

sources:
  - id: requirements
    title: System Requirements
    model: rtm
    query:
      from: UserNeed
      where: "type:userNeed"
    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 a Lucene-compatible equality predicate (type:)
The applyCurrentDocumentTo constraint restricts results to the current document context
Expansion paths load related entities after the primary query executes

Predicates — predicate types and syntax
Document Filtering — document-level query constraints
Expand Clause — expansion path configuration
Query Context — query parameters and execution context

​Splitting Strategy

​Predicate Classification

​Query Execution Pipeline

​Document Query Optimization

​Query Parameters

​Security Enforcement

​Constraint Annotations

​Complete YAML Example

​Related Pages

Splitting Strategy

Predicate Classification

Query Execution Pipeline

Document Query Optimization

Query Parameters

Security Enforcement

Constraint Annotations

Complete YAML Example

Related Pages