-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support projections #947
Comments
Would generating the projections from the entity classes allow to have pure data classes without realm dependencies? I'm currently doing this manually. The biggest problem is using flows instead of RealmLists which behave differently when comparing equality of data classes. Maybe I need a custom class that implements the List interface using flows... |
That is one of the things we want to explore. It would be possible, but would result in some runtime overhead as we would need to calculate/validate that we can actually copy data correctly. Would even adding a single annotation to the data class be too much, ie.?
|
Can you also elaborate on |
I want to be able to keep observing changes on oneToMany relations in my pure data classes which are generated from the realm classes. So I convert the RealmList to a Flow and then to a StateFlow which I then keep in my data class. However when comparing data classes for equality List behaves different to StateFlow<List>. With lists its actual content is compared while StateFlows are compared by instance (like arrays which generate IDE warnings when used in data classes for that reason). |
Personally I don't mind having @Projection as an annotation but when trying to clean the ui from a realm dependency does it matter to have just an annotation as a dependency or classes or whatever? |
You should unify the MongoDB Atlas( Kotlin driver)UI data layer with Atlas Device SDK UI data layer to increase sharing code, especially for jetpack compose multiplatform |
Any update in this Issue |
Any update on this Issue |
Hello, It's a really cool idea, and it can really help us with our projects, so any update on this issue ? |
Similar to the ideas expressed here: realm/realm-java#5426 and as exposed by Cocoa here: realm/realm-swift#7375
Projections would decouple the model classes (Database Entity) from how the data is being used in the UI (View Model classes). Which would solve a few use cases
Reduce the coupling between layers. A common criticism is that Realm is spreading throughout the entire app as you use the model classes.
More type-safe API as projections would only expose data actually needed.
Data classes could be used as projection classes as the data is read-only.
Preload all data on a background thread, instead of relying on lazy-loading. As the expectation is that all projection fields are being read, we could also bulk-fetch these as an optimization. Something that isn't really possible with our model classes.
We would need to iterate on the exact API and functionality, but something like this:
The text was updated successfully, but these errors were encountered: