-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: API design
-
Labels:None
-
3
-
86
-
Kotlin Beta sprint 14, Kotlin Beta sprint 15, Kotlin Beta sprint 16, Kotlin Beta sprint 17, Kotlin Beta sprint 18
In Realm Java we right now have a complete Dynamic Realm API. It was developed to assist with the manual migrations, but also have other uses, like people creating really dynamic code like a Realm database browser.
For Realm Kotlin we need to figure out exactly how this API should look like. The original API has quite a few annoying implementation details. This mostly comes from the fact that DynamicRealmObject _ is a subclass of _RealmObject and we use the same types (RealmList and RealmResults) to expose them.
With method count no longer being a big concern we should consider if we should expose the dynamic data through their completely own types. This would also fix some annoyances, like `RealmObject.getRealm()` throwing an exception for DynamicRealmObject.
TODO/Questions
- To what degree do we need to support a Dynamic API in we start by exposing automatic migrations as done in other SDK's?
- If we end up with a full-blown Dynamic API, how should it look like?
- Writeup pros/cons for different proposals.
- is depended on by
-
RKOTLIN-141 Story: MVP Automatic Migration support
- Closed