It should be easy to implement properties of type int[] or List
Affects also queries however:
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
@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).
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.
What's the status on this?
_It's been 85 years_
We are committed to this. Timing wise we have prioritized other features the next 2 months. For storing, you can use a converter today.
Hi Markus, any updates on this one?
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
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
If you'll finally implement this feature, I swear I'll buy you a coffee! ☕
Any update on this feature?
It's nearly been 2 years, and no progress
I will have to move to another database lib because of this :(
That will be better, frankly I have used room & Objectbox both, I will choose room over ObjectBox everytime
@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.
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.
@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.
@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
Most helpful comment
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.