Array of Primitives: Support queries

[cmelchior]

Split from #5031

We need to add support for arrays of values to RealmQuery. Based on API discussions we don't want to add a ton of extra methods, so instead we are going to use the empty field name "" when querying arrays of primitives.

E.g

public class Person extends RealmObject {
  public RealmList<String> names;
}

// Query list in object
RealmResults<Person> results =  realm.where(Person.class).equalTo("names", "John").findAll();

This also include support for RealmList.min()/max()/average()/sum()/minDate()/maxDate() which depends on the query system

Out of scope for now

// Query list directly
Person p = getPerson();
RealmResults<String> results = p.names.where().like("", "Jo*").findAll();

[Zhuinden]

I actually think

// Query list in object
RealmResults<Person> results =  realm.where(Person.class).equalTo("names", "John").findAll();

has a higher importance than the others, so that you can replace RealmString link queries with it.

[cmelchior]

Yes. No doubt about that

[vivekkiran]

Any progress/updates on this? I am eagerly waiting for this feature to support the primitive list from my Wordpress API the native way without a wrapper. :)

[Zhuinden]

Agreed, I was hoping for end of 2017, but maybe this year 😄

Surprised it's blocked, I thought subtable query does this.

[mgohin]

+1, I have to use .findAll() and filter in java :(

[Zhuinden]

@mgohin another option of course is to map the list into a single string field with some convention like |value1|value2|value3| and then contains("flatList", "|${searchValue}|")

But that's lame that we still have to do that, i agree

[amaslanka]

+1

[aritrobanerjee93]

Hi,
Any update on this much needed feature? It's 2019 and I don't think using a wrapper seems agreeable anymore.
If anyone has a workaround apart from flatlists, I would love to learn!

[ismdcf]

Hi @Zhuinden

Any updates for this or what is the best workaround that u suggest for this

[bmunkholm]

It's something we expect to prioritize "soonish" - but we are currently prioritizing getting Core6 tested, integrated and rolled out. I know that doesn't say much in terms of timeline, but it's unlikely to happen on this side of New Year.

[ismdcf]

@bmunkholm
Can you suggest a workaround for this other than writing a custom deserializer which we removed after the introduction of primitive data realm list

[Zhuinden]

@ismdcf I've already posted the workaround, as unfortunate as it is: #5361 (comment)

For Realm's roadmap, take a look at https://www.mongodb.com/realm#roadmap

Estimated January 2020 through July 2020

Realm Database and Realm Cloud

After releasing Realm Database (Core) 6.0, we’ll be able to start building exciting new functionality that we’ve heard requested from the Realm community.

In Realm Database 6.1 and 6.2 expect to see features like:

• Support for embedded objects, dictionaries, and mixed types in the Realm Schema: have more flexibility in how you map, store, and interact with your data so that you can build a highly performant app.

• Support for Query Operators on Single-Typed Arrays: interact with arrays in Realm to run more powerful queries, meaning faster data processing and simpler code.

• Realm sharing between apps: allow a device to share one Realm across multiple apps, making it simple to keep data consistent across a suite of apps regardless of connectivity.

So you should probably map them to a single String field with separators and expect the feature for July 2020.

The good old RealmList<RealmString> also works but I recommend against it.

[bmunkholm]

This has now been implemented in Core and ObjectStore, awaiting implementation here.

[RealmBot]

➤ Claus Rørbech commented:

The currently used old syntax for queries does not support querying on primitive list elements. Filed this with core in RCORE-309.

[rorbech]

➤ Claus Rørbech commented:

The currently used old syntax for queries does not support querying on primitive list elements. Filed this with core in RCORE-309.

Since we have migrated to use the query parser API internally we could maybe revisit this 🤔