[MGNLREST-120] Implement filtering operators Created: 04/Oct/17  Updated: 09/Jan/18  Resolved: 06/Jan/18

Status: Closed
Project: Magnolia REST Framework
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.2

Type: New Feature Priority: Neutral
Reporter: Hieu Nguyen Duc Assignee: Hieu Nguyen Duc
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 4.25d
Original Estimate: 4d

Issue Links:
Relates
relates to MGNLREST-122 Support additive filters via multiple... Closed
dependency
depends upon MGNLREST-105 Implement filter on lists Closed
Template:
Acceptance criteria:
Empty
Documentation update required:
Yes
Date of First Response:
Epic Link: REST Queries
Sprint: Saigon 126, Saigon 127, Saigon 128, Saigon 129
Story Points: 5

 Description   

Query params are parsed as key=value, so the operator needs to be included on either side of the equal sign.
Syntax to be defined; worth checking whether there are established conventions for this.

Contentful does the it with bracket operators on the key side (see reference);

/spaces/{space_id}/entries?{property}[gte]={value}

=> filter where "property" is greater than or equal to "value"



 Comments   
Comment by Mikaël Geljić [ 15/Dec/17 ]

High-level flavor

  • document-based predicate filtering, JSON/mongo-ish, quite technical
  • dedicated facade (polyglot) client API (e.g. prismic)
  • ✓ simple property-based, this is the same direction we have already

Operator syntax

  • ✓ square brackets are ideal because illegal in JCR names

Comparators

  • named-operators vs. sign-operators
  • JCR queries use signs
  • but equals already used to separate param key-values
  • ✓ named-operators more readable than sign-operators

Range operators

  • [in] operator more fluently-readable than combining comparators
  • which range-splitting character? tilde ~, dash -, or?
    • dash won't work for dates, tilde sounds ok
  • how to combine with negation? also provide [not-in]? — not mandatory
  • we do not support non-continuous ranges

Negation operator

  • ! or ne?
  • not vs. ne? same meaning?
  • generic operator?
  • vs. ✓ specific counter-operators (in vs. not-in, eq vs. ne)
    • can change impl later if needed

Date filtering

  • date comparison: see examples below, no specific difference vs. long comparisons
  • supported date formats are OK, no need to change
    • 2015-01-26 ==> translates to ==> 2015-01-26T00:00:00.000+00:00 for JCR queries
    • UTC-based?
    • 2015-01-26T23:17:02.306+07:00

Partial string matching

  • how does current full-text search works? (contains?)
  • which operators to provide?
    • [like] vs. [contains] and [startswith]
    • value would have to be treated as 'foo%' vs. '%foo%'
  • ok to start simple and support 'like' (if well understood by users)
  • negation support?
    • nice if [ne] works in conjunction?
    • not critical - keep it for another ticket if there is (strong) demand

Allow to define custom operators?

  • ✓ not for now, would investigate only if there is (strong) demand
  • would involve letting users code the translation logic between operator and JCR where clause

The issue with tours duration

  • problem of the model! (not the query)
    • comparisons will not work with Strings, no way for us to know when to cast
  • duration property must be migrated to Long (setting type in FieldDefinition)

Examples

…?location[ne]=Basel

…?duration=7
…?duration>=7  //confusing
…?duration>==7  //equally confusing
…?duration[gte]=7&duration[lte]=14  //possible, not best

…?duration[in]=7~14
…?duration[not-in]=7~14

…?duration[eq]=7  //should be equivalent to …?duration=7
…?duration[ne]=7

…?startDate=2017-12-15
…?startDate[gte]=2017-12-15
…?startDate[in]=2017-12-00~2017-12-15
Comment by Mikaël Geljić [ 15/Dec/17 ]

Goal for next week is to:

  • validate how far we support this already
  • document the supported operators
Comment by Hieu Nguyen Duc [ 08/Jan/18 ]

The final scope of this ticket is described in Concept page.
https://wiki.magnolia-cms.com/display/VN/REST+Filtering+Operators

Comment by Ngoc Nguyenthanh [ 09/Jan/18 ]

Date format should remain consistent across operators. Now it works differently between gt vs lt

Comment by Hieu Nguyen Duc [ 09/Jan/18 ]

If the input date format is not correct, it defaults to String comparison and output result is unpredictable.

+ [gt] case

SELECT t.* FROM [nt:base] AS t WHERE t.[jcr:primaryType] = 'mgnl:page' AND t.[mgnl:created] > '2017-1-1' ORDER BY LOWER(NAME(t))

+ [lt] case

SELECT t.* FROM [nt:base] AS t WHERE t.[jcr:primaryType] = 'mgnl:page' AND t.[mgnl:created] < '2017-1-1' ORDER BY LOWER(NAME(t))
Generated at Mon Feb 12 06:56:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.