[MGNLREST-150] Filtering doesn't work when parameter is integer but property is a string Created: 20/Nov/17  Updated: 27/Mar/18  Resolved: 19/Jan/18

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

Type: Bug Priority: Major
Reporter: Christopher Zimmermann Assignee: Sang Ngo Huu
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1.5h
Time Spent: 1d 6.5h
Original Estimate: 2d

Issue Links:
Relates
relation
is related to MGNLDEMO-261 Tours durations are stored as String ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Documentation update required:
Yes
Date of First Response:
Epic Link: REST Phase2
Sprint: Saigon 127, Saigon 128, Saigon 129, Saigon 130
Story Points: 5

 Description   

The query returns no results when you supply an integer as a filtering parameter, but the property in the JCR content has type String.

For example:
http://localhost:8080/magnoliaAuthor/.rest/delivery/tours/v1?duration=7

However if I change the type of the delivery property in the tours to a Long instead of a String, then the tours are correctly returned.



 Comments   
Comment by Christopher Zimmermann [ 20/Nov/17 ]

Probably related to https://jira.magnolia-cms.com/browse/MGNLREST-123

Comment by Sang Ngo Huu [ 12/Dec/17 ]

Could we use or operator for this case: WHERE duration="7" or duration=7 ?

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

sang.ngo maybe we'd have to do that, yeah. For strict equality, we can find cases for matching these both as numbers (duration) or as strings (zip code).

Also bear in mind that this could result in false-positives, due to implementation of string comparison.

Comment by Mikaël Geljić [ 03/Jan/18 ]

Welcoming Sang's latest suggestion here: escaping the filter's value in the request when type is ambiguous. This addresses the hypothetical zip-code use case I described above (until CT models tell us it is a string and we no longer have to infer). Below is an example

…?zipcode="06988"
…?zipcode[gt]="06900"

Meanwhile for tours duration, duration is a legit number property, and comparison constraints are expected to behave as such. It is a mistake to store these as strings. I filed MGNLDEMO-261 for this.

Generated at Mon Feb 12 06:57:06 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.