-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
?
-
1077
-
Needed
Description
We build Realm .query's dynamically, for example when allowing users within the Flutter UI to filter/sort/search a Realm model/collection via .query
- allowing the user to filter by XYZ params, etc by clicking on checkboxes, etc. Currently the 'keys' in the .query have to be hard coded using the @MapTo key from the RealmObject property, which is not ideal from a maintenance perspective. I.e. final hobbits = fellowshipOfTheRing.members.query('first_name == "Hobbit"');
To get over this 'hard coding', it would be great if we could access the RealmObject property (as a string) and related @MapTo property (as a string) as follows:
- p.firstName.name // outputs string firstName
- p.firstName.mapToName // outputs string first_name (@MapTo property for p.firstName)
- p.firstName.mapToNameOrName // outputs no 2 above, falls back to option 1 if no 2 @MapTo does not exist
Or it may be better to p.firstName.reamlName (or similar) which outputs whatever the property is in the Realm local DB...i.e. as .query essentially needs this whether its no 1 or 2 above.
This allows us to take advantage of darts strict typing when building Realm .query's, which would be amazing;
// i.e. p.firstName.name would output firstName as a string
Option 1: final hobbits = fellowshipOfTheRing.members.query('${p.firstName.name} == "Hobbit"');
or
// i.e. p.firstName.mapToName would output first_name as a string (i.e. the p.firstName @MapTo)
Option 2: final hobbits = fellowshipOfTheRing.members.query('${p.firstName.mapToName} == "Hobbit"');
Either route would work very well. There are also lots of other use cases for this...such as dynamically building CSVs from RealmResults, please see https://github.com/realm/realm-dart/issues/1076
To add to this re .query params in embedded objects/lists
It would also be good if we could access embedded arrays/lists via dot notation (or by some other way to give the same effect as the above two options). So for example (we have not tested .query with params within embedded lists/objects yet so we are 'assuming' this is possible) if we could:
// i.e. p.friends.friends.name }}would output {{friends.firstName as a string
Option 1: final hobbits = fellowshipOfTheRing.members.query('${p.friends.firstName.name} == "Hobbit"');
or
// i.e. p.friends.firstName.mapToName would output friends.first_name as a string (i.e. the p.firstName @MapTo)
Option 2: final hobbits = fellowshipOfTheRing.members.query('${p.friends.firstName.mapToName} == "Hobbit"');
How important is this improvement for you?
Would be a major improvement
- depends on
-
RDART-531 Realm Linq like syntax
- Backlog