Skip to main content
diagram

Predicate Types

TypeDescriptionOperators
Binary predicateCompares a single property value against a constanteq, ne, gt, ge, lt, le, contains
Composite predicateCombines multiple predicates with logical AND or ORand, or
Collection quantifierEvaluates a predicate across multi-valued navigation propertiesany, all

Binary Predicates

A binary predicate compares one entity property against a value using a comparison operator.

Syntax

Full form:
propertyName:
  operator: "value"
Shorthand equality form (equivalent to eq):
propertyName: "value"

Comparison Operators

OperatorAliasSupported TypesDescription
eq==String, number, booleanExact equality. Case-sensitive for strings.
ne!=String, number, booleanInequality.
gt>Number (Integer, Double, Long), dateGreater than.
ge>=Number, dateGreater than or equal.
lt<Number, dateLess than.
le<=Number, dateLess than or equal.
containsStringCase-sensitive substring match.
The gt, ge, lt, and le operators work with Integer, Double, and Long values. They are not applicable to string or boolean properties.

Examples

Equality — exact match on a property value:
title:
  eq: "System Requirement 1"
Shorthand form produces the same result:
title: "System Requirement 1"
Both translate to the Lucene query title:"System Requirement 1". Inequality — exclude a specific value:
status:
  ne: "rejected"
Numeric comparison — range filtering on numeric properties:
priority:
  gt: 3
Inclusive upper bound:
severity:
  le: 5
String contains — substring search (case-sensitive):
title:
  contains: "safety"

Null Predicates

Null checks test whether a property has a value or is empty. Use eq or ne with a null value. Property has no value:
title:
  eq: null
Property has a value:
title:
  ne: null
ExpressionLucene TranslationMeaning
prop: { eq: null }NOT HAS_VALUE:propProperty is empty
prop: { ne: null }HAS_VALUE:propProperty has a value
The HAS_VALUE pseudo-field is a Polarion-specific Lucene construct for checking property existence. The server API translates null predicates into this syntax automatically.

Composite Predicates

Composite predicates combine multiple sub-predicates using logical AND or OR operators.

AND Predicate

All sub-predicates must match. Wrap conditions in an and array:
and:
  - status:
      eq: "approved"
  - priority:
      gt: 2
Translates to Lucene: (status:"approved") AND (priority:{2 TO *})

OR Predicate

Any sub-predicate may match. Wrap conditions in an or array:
or:
  - status: "draft"
  - status: "in_review"
Translates to Lucene: (status:"draft") OR (status:"in_review")

Nested Composites

AND and OR predicates can be nested to build complex filtering logic:
and:
  - priority:
      ge: 3
  - or:
      - status: "approved"
      - status: "in_review"
Resulting Lucene: (priority:[3 TO *]) AND ((status:"approved") OR (status:"in_review"))
AND binds more tightly than OR. Each operand in composite predicates is parenthesized during Lucene translation to maintain correct evaluation order. Use explicit nesting when combining AND and OR to ensure predictable results.

Collection Quantifiers

Collection quantifiers evaluate predicates against multi-valued navigation properties (related entity collections).
QuantifierAliasDescription
anysomeReturns true if any element in the collection matches the condition
alleveryReturns true if all elements in the collection match the condition
any uses short-circuit evaluation — it stops at the first match for performance. all returns false at the first non-match. It is used in validation rules and completeness checks.
Collection quantifiers are used for filtering across related entity collections. The exact query syntax for any and all with nested property conditions depends on the entity type metadata and the relationship configuration in the domain model.

ObjectId Predicates

Query a specific entity by its Polarion work item ID:
objectId: "UN-001"
With project prefix:
objectId: "myProject/UN-001"
The project prefix format project/id expands to a compound query: project.id:"myProject" AND id:"UN-001".

Data Property Predicates

Predicates on entity data properties are validated against the entity type schema before execution. Only scalar (non-navigation) properties are supported in direct predicates. The server API processes the where clause by:
  1. Extracting all property names from the predicate
  2. Matching each property against the entity type metadata
  3. Rejecting predicates that reference unknown or navigation properties
  4. Combining validated predicates with AND logic
If a predicate references a property that does not exist in the entity type metadata, the query will fail with a validation error. Always use property names exactly as defined in the domain model.
For navigation property filtering (document or project scoping), use the dedicated constraint system. See Document Filtering and Query Context.

Document and Project Predicates

Document and project predicates filter by navigation properties and are extracted separately from data property predicates. Document filtering:
document:
  moduleName: "Requirements"
  moduleFolder: "Specifications"
Project filtering:
project:
  id: "myProject"
Cross-project queries are not supported. All queries execute within a single project scope. The project predicate is used to specify which project to query, not to query across multiple projects simultaneously.
When the project predicate contains only an id field, the server API uses a simplified Lucene query (project.id:value). More complex project predicates undergo full predicate evaluation against the Project entity type metadata.

Where Clause Merging

When multiple filter conditions are combined (for example, from user-applied filters and sheet configuration constraints), Powersheet merges them using these rules:
ScenarioMerge Behavior
Two AND predicatesArrays are concatenated
Two OR predicatesArrays are concatenated
AND + ORThe OR predicate is wrapped inside the AND
Property conflictsThe second value overrides the first
Empty/undefinedIgnored silently

Lucene Translation Summary

Predicates are translated to Polarion Lucene query syntax before execution against the data store.
PredicateLucene Output
name: "John"name:"John"
count: 5count:5
prop: { ne: "X" }NOT prop:"X"
prop: { gt: 3 }prop:{3 TO *}
prop: { ge: 3 }prop:[3 TO *]
prop: { lt: 10 }prop:{* TO 10}
prop: { le: 10 }prop:[* TO 10]
prop: { eq: null }NOT HAS_VALUE:prop
prop: { ne: null }HAS_VALUE:prop
and: [...](...) AND (...)
or: [...](...) OR (...)

Complete YAML Example

A source configuration with predicates applied through the where clause:
sources:
  - id: filtered-requirements
    title: Active Requirements
    model: rtm
    query:
      from: UserNeed
      where:
        and:
          - title:
              ne: null
          - or:
              - status: approved
              - status: in_review
          - priority:
              ge: 3
      expand:
        - name: systemRequirements
    constraints:
      applyCurrentDocumentTo: UserNeed
This query:
  • Targets UserNeed entities
  • Requires a non-null title
  • Limits results to approved or in_review status
  • Requires priority of 3 or higher
  • Expands the systemRequirements navigation property
  • Scopes results to the current document

Predicate Type Compatibility

The following table summarizes which Polarion custom field types are compatible with each operator:
Field Typeeq / negt / ge / lt / lecontainsNull checks
string
integer
float
boolean
date
richtext
currency
duration


Source Code
  • Query.java — predicate extraction, validation, and document/project filtering
  • QueryExecutorTest.java — binary, composite, and collection predicate integration tests
  • QueryDataTest.java — primitive field types, null predicates, expansion queries
  • GenericQueryResolver.java — Lucene query execution and project scoping
  • OrderByClause.java — property path validation for sorting
  • ModelProvider.tsx — metadata integration and enum source generation