equalTo() fails to find null values on an indexed field if using Case.INSENSITIVE
See original GitHub issueIt appears that Realm versions from 3.1.3 onward have a bug where using equalTo() on a query no longer finds indexed fields which have null values, but only when the Case.INSENSITIVE flag is being used. Using Case.SENSITIVE (the default) still works.
In the Realm Java changelog for 3.1.3 we can see the following under enhancements:
Upgraded to Realm Core 2.6.1.
We can see in the Realm Core changelog for 2.6.0 the following, which looks like it could be the culprit:
Made case insensitive queries use the new index based case insensitive search. PR #2486
Expected Results
I would expect to be able to find records whose values for the field we’re searching on are
null
Actual Results
No records are found
Code Sample
RealmTest.class is a subclass of RealmObject and defines test_field like so:
@Index
private String test_field;
Now the query:
Realm realm = Realm.getDefaultInstance();
String searchString = "test";
realm.where(RealmTest.class)
.equalTo("test_field", searchString, Case.INSENSITIVE)
.findAll();
// 3.1.0 behaviour: returns all results where test_field has a value of "test" ✅
// 3.1.3 behaviour: returns all results where test_field has a value of "test" ✅
searchString = null;
realm.where(RealmTest.class)
.equalTo("test_field", searchString, Case.INSENSITIVE)
.findAll();
// 3.1.0 behaviour: returns all results where test_field has a value of null ✅
// 3.1.3 behaviour: does NOT return results where test_field has a value of null ❌
Again, this bug is only seen when Case.INSENSITIVE is used, which makes me suspicious that Realm-Core PR #2486 might be the cause of this issue, but I’m not sure.
Version of Realm and tooling
Realm version(s): >= 3.1.3
Realm sync feature enabled: no
Android Studio version: 2.3.3
Which Android version and device: 8.0, Pixel.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (3 by maintainers)

Top Related StackOverflow Question
@ironage brilliant, thanks for the super fast turnaround on this one!
Fixed in 4.0.0-RC1. Closing