> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Query Splitting > Nextedy POWERSHEET splits entity query predicates into two execution stages: Lucene-compatible predicates that execute as database queries, and complex predicates that execute as in-memory post-filters. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; ## Splitting Strategy diagram ## 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: 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. | 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](/powersheet/reference/query-api/query-context) and [Baseline and Revision Queries](/powersheet/reference/query-api/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](/powersheet/reference/data-model/constraints) for data model constraint configuration. ## Complete YAML Example ```yaml theme={null} 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 ## Related Pages * [Predicates](/powersheet/reference/query-api/predicates) -- predicate types and syntax * [Document Filtering](/powersheet/reference/query-api/document-filtering) -- document-level query constraints * [Expand Clause](/powersheet/reference/query-api/expand-clause) -- expansion path configuration * [Query Context](/powersheet/reference/query-api/query-context) -- query parameters and execution context