[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: |
|
||||||||||||
| 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: 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
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 |