Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Genesys Backend Genesys Backend
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 25
    • Issues 25
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Genesys PGR
  • Genesys BackendGenesys Backend
  • Issues
  • #615
Closed
Open
Created Nov 16, 2021 by Matija Obreza@mobrezaOwner

Filters with OR support

Our current filters implementation supports proper NOT filtering and is designed as an AND operation (all specified criteria must be true). This covers two of the three core boolean operations. By adding support for OR filtering, we have the full coverage of all possible filtering combinations, since all boolean operations can be broken down to the core AND, OR and NOT.

filter1 AND filter2 can be achieved by simply merging all properties of the two filters, while our NOT implementation fully embeds the not filter as a separate object.

In this ticket we extend SuperModelFilter<T> with

class SuperModelFilter<T> {
//  @JsonIgnoreProperties({ "NOT", "NULL", "NOTNULL" }) // we do not allow nesting in JSON!
  @JsonIgnoreProperties({ "NOT", "NULL", "NOTNULL", "AND", "OR" })
  public T NOT;
  // New!
  public T OR;
  public T AND; // maybe
}

Multiple OR operations f1 OR f2 OR f3 can be achieved by f1.OR(f2.OR(f3)). f1 AND f2 AND f3 operations are implemented as f1.AND(f2.AND(f3)).

It appears that only an update to SuperModelFilter::collectPredicates method will be required. It appears that ElasticQueryBuilder already handles or, and and not operations, since those are part of regular JPA conversion to ES query.

It is unlikely that we would be serializing complex filter expression to JSON, we already prevent deep serialization of the current public T NOT expression. Implementing UI support for such nested queries would be quite complicated.

Uses

The primary use of this update is to allow the backend to use advanced JPA and ES queries.

Assignee
Assign to
Time tracking