Add support for multi-field comparisons

[ghost]

How to compare two fields in android realm.io ?

[emanuelez]

We currently we don't support multi-field comparisons in the Java API, mostly because it's hard to make a nice API for it. We are thinking about some possible options.

[cmelchior]

Just adding equalToField would probably be easy, but the list is also a bit bigger which complicates it:

• notEqualTo
• Compare integer fields: lessThan, biggerThan, etc.
• Calculations on integer fields, eg. 2 * field1 > field2
• does contains/startsWith/endsWith work on multiple fields?

[brozot]

+1

Hello I need to use this solution to make this comparison : updateDate > syncDate (these two dates are in the database). I want to fetch only the updated entities or there is another solution for this?

[saket]

Please consider adding support for this. I've been running equalTo and other operators in a loop for multiple arguments :(

[eyalfein]

Came here looking for solution to this problem (now missing feature) too.
Looks like there is significant demand for it.
I am hoping it will be in the form of:
.equalTo(string, string), notEqualTo(string, string), etc - to compare compare two properties of the same entity.

[papagno]

No workaround at the moment? I can't select comparing two columns in any way?

[bmunkholm]

One workaround is to add a third boolean which is the result of the comparison you wan to make. You would then need to update that whenever the properties you compare changes.

The Core does support this, so anyone with time can make a PR. The first task is to propose a proper API, then it is trivial to implement (I'll be happy to provide pointers to the core API).

[nachogarrone]

I would like to have this feature too!

I want to filter my RealmResults in my adapter when the user types in a search text view. I want to filter by all the fields in RealmResults.

Example:
firstName -- lastName
John -- Johnnes

constraint = "John J"
mRealmObjectList.where().contains("firstName", String.valueOf(constraint), Case.INSENSITIVE).or().contains("lastName", String.valueOf(constraint), Case.INSENSITIVE)

This wouldn't receive any record.

My workaround is to get all the fields in a temporal string and do the contains() in there. But i wonder how much it will cost if my table has a lot of rows...

[letronje]

+1 for this

[acib708]

+1 for calculations on integer fields, eg. (qty / dailyAvg) < 3

[vostreltsov]

+1

[N-Olifer]

+1

[samvanderhyden]

+1 on this - it is possible in realm cocoa, seems like it should be here to!

[cmelchior]

The most common cases could probably be solved by adding the following methods

equalToField(field1, field2);
greaterThanField(field1, field2);
greaterThanOrEqualToField(field1, field2);
lessThanField(field1, field2);
lessThanOrEqualToField(field1, field2);
notEqualToField(field1, field2);

[Zhuinden]

I'm not sure how common this actually is. A possible workaround for now of course is to store the actual boolean for the fields you are interested in, and update it in the two setters.

This feels like one of those things that would be better solved by exposing the query language that is already processed by partial sync preview api: #1573 (comment)

[tristangrichard]

+1

[abou7mied]

+1
Any updates?

[w19787]

this issue has been open for couple years! any update?

[BosAtWork]

I also run into this issue while making an Android app based on an already existing Objective-C codebase.

I find quite a few things in the java bindings that are supported in other platforms and the core but the Java team won't add support with the same API used on other platforms. Quite frustrating when used to the binding of another language. Realm is an awesome tech don't get me wrong but I would like all bindings teams to pull all API's together.

[Qubitium]

Bump this. This is not just implementation issue but a performance issue. Currently users are relagated to do this to simluate the effect (kotlin). f1 and f2 are numeric.

r.where(table).filter { row.f1 < row.f2 }

The above looks simple enough but performance-wise we are doing filtering (with lots of native calls plus allocations) in jvm runtime rather than c++. With lots of rows this becomes a huge issue.

The current accepted work-around is the "additional field computed" comparison but this method is not sustainable in a normal dev env where logic change all the time. Imagine changing schema and/or adding migration every time this logic changes. Yikes.

[inri]

Even worse if one of the values is updated by copyToRealmOrUpdate() with a JSON, so the setter for the Boolean-field won't be called and updated properly. Or am I wrong?

A big +1 from me too.

[ios4vn]

+1

[funct7]

Still? 😞

[Zhuinden]

Still hoping for optional support of #5730 with a flag

[cmelchior]

#6116 merged support for String-based query predicates, which should support this. This will be part of 10.4.0.