Support list/array type properties

[greenrobot]

It should be easy to implement properties of type int[] or List.

Affects also queries however:

• how is something like "greater than X" defined? All values? At least one value? Maybe we would need additional info here

[homj]

That's the dealbreaker for me at the moment.

Do you have a timeframe in mind when this feature will be added?

While we're at it: I'd also love to see support for Sets and Maps

[greenrobot]

@homj No timeline yet. Might be quick depending on its relevance for to-many relations. But cannot promise yet. Will keep Sets and Maps in mind - if it's not too complicated, maybe we can just implement everything at once.

What are your requirements excatly, do you also need to query for array/list/set/map values? If so, how (== >, !=, IN, contains, all, etc.)?

Be aware that this will be only offered for built-in types (integers, floating, and strings).

[ArthurSav]

Coming from realm, which has the same issue, this would be a major addition that saves us from writing boilderplate code.

The main use case(for me) is when we convert json to POJOs and the json contains a list of strings/primitives.

To be able to query the list values would be nice, but just storing it is enough for me.

[ArthurSav]

What's the status on this? It's been 85 years

[greenrobot]

We are committed to this. Timing wise we have prioritized other features the next 2 months. For storing, you can use a converter today.

[fr-johannes]

Hi Markus, any updates on this one?

[greenrobot]

We don't usually comment on time estimates. However, here's an exception to the rule: we try to be be quicker than that:

It's been 85 years

[cflannery91]

Definite push for this one, would be a huge plus for me to not have to create 30+ custom converter classes! Keep up the good work Markus

[gryphon2411]

If you'll finally implement this feature, I swear I'll buy you a coffee! ☕

[jonathansds]

Any update on this feature?

[sanjeevyadavIT]

It's nearly been 2 years, and no progress

[gyorgygabor]

I will have to move to another database lib because of this :(

[sanjeevyadavIT]

That will be better, frankly I have used room & Objectbox both, I will choose room over ObjectBox everytime

[greenrobot-team]

@gyorgygabor @alexakasanjeev Note: similar to Room's @TypeConverter you can already use the @Convert annotation (on a property). Though granted, it only supports lists and not arrays as @Convert requires a converter implementation instead of an annotated method.

[fr-johannes]

Adding to @greenrobot-team 's comment, if you are using Kotlin it's very easy to write a generic converter and then add new converter classes in one liners like

class CustomConverterA : StringConverter<List<CustomObject>> by listConverter()

Provided you want to use the same serialization mechanism every time, of course.

[cyberquarks]

@greenrobot Hello,

Would this work with ObjectBox?

class Hub {
    List<Schedule> schedules; 
}

class Schedule {
    String day;
    LocalTime opens;
    LocalTime closes;
}

And then query those Hubs which opens and closes during a specific day, say, query with this constraint:

new Schedule().builder()
    .day("Monday")
    .opens(LocalTime.parse("08:00")
    .close(LocalTime.parse("17:00").build();

So in this case we want to query for Hubs that are open on Mondays at 8am to 5pm.

[greenrobot]

@cyberquarks this is somewhat offtopic, please check the docs on queries, relations and links. Especially here: https://docs.objectbox.io/queries#add-query-conditions-for-related-entities-links

[greenrobot]

A little update: 3.0 (released today) makes the first step by supporting String lists/arrays. Query support is limited to "contains an element matching a given value".

Leaving queries aside, basic support for primitive type lists would be the next step.