This means that we totally avoid the impedance mismatch when you try to map Java references to tables. In Realm, relationships are first-class citizens.
This is also one of the reasons that we can provide lazy-loading for everything. With ORM's the API might look the same on the surface, but you usually run into problems when trying to access foreign collections.
API wise we try to stay as close to normal Java as possible, which is probably why it looks similar to what Hibernate offers.
Regarding specific features.
- Realm uses zero-copy as much as possible, so collections in Java point directly to the underlying data (i.e takes almost no space on the Java heap).
- Collections are live updated yes.
- Deleted objects could potentially be accessed after they are deleted, but there is API methods for avoiding that.
- Cascading deletes is not supported yet, but really high on our TODO and definitely a feature we want to add.
Yeah well, literally ORM has relational in it, but you probably know what I mean.
So it behaves more like a graph store? - Can I query bottom up / through collections ?
I'm really interested in the technical details and their implications.
We don't have support for collecting objects bottom up yet, bu t it is tracked here: https://github.com/realm/realm-java/issues/2232
Realm Swift/Objective C has support for bi-directional references and we are adding that to Realm Java shortly as well: https://github.com/realm/realm-java/issues/607 ..That will also help when doing bottom-up queries.
If you want to know more about the internal details. There is some talks/articles here that might interest you:
- https://realm.io/news/threading-deep-dive/
- https://realm.io/news/jp-simard-realm-core-database-engine/
I'm reading through the docs and it seems very appealing. Especially the Observability of changes. I assume this works well because it is contained in one Process.
The examples look suspiciously similar.
EDIT: So i easily believe that it's nicer than CoreData, and I see that there is lots of potential to reduce an ORMs complexity by assuming a single Writer (Process of App), but the core Problem seems to be exactly the same. - And the solution looks also very familiar. -> Proxy Objects, Bytecode manipulation to intercept field access etc.
Does it handle the uncool cases of ORMs better? - Unloading of state when thousands/millions of objects are touched once
- Collection fetching of large collections, iterators/chunks
- OrderedList O(N) index update for non-append inserts
- What happens to invalidated (deleted) objects? are collections updated live?
- Does is handle cascades explicitly/implicitly/not ?
I'm quite interested in this, since it may solve real pain problems.