Great job on the recent additions to the more fine grain notifications, with this I was recently able to reduce my own code, simplify and increase performance!
Core data is good and a powerful weapon, and certainly educational to learn its approach and how to use it effectively. I sometimes ponder if going through the that first has made me a more competent iOS developer.
Realm is the right tool for the job for me in most use cases. Don't see myself switching back anytime soon, keep up the good work!
this is handled by the applications code, which inserts data primarily from a rest api into realm in a background thread. Not all data comes from rest however, some from apns or xmpp, depending on application state and the particular data.
Syncing is hard to get right. If realm offered it I would consider but I would not want them to do that at the sacrifice of making their product as solid as it is.
How does couch handle it? Does it have push and poll type of hooks?
1. Since Realm is not a relational database with an ORM, we don't run into the impedance mismatch. Relationships are first-class citizens.
2. Realm uses a zero-copy architecture. Objects and collections are lazy loaded offering benefits to both memory use and speed.
- simplicity, which in turns creates less complex code and less crashes
- performance, which for my use case was faster than sqlite
- slightly opinionated, in that it forces you to not access objects from different threads, which can eliminate a whole class of bugs (you could and should do this or a similar approach to prevent these with whatever solution, but Realm forces it)
If you are interested in mobile databases, you'd do well to evaluate Cocuhbase Mobile, which is 100% open source, available for most mobile platforms, and includes bulletproof synchronization with its open source secure cloud server.
More info here http://developer.couchbase.com/mobile/
Do you have any comparison metrics of Couchbase and Realm or other mobile Databases?
The examples look suspiciously similar.
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.
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:
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.
I've had to deal with enough pain from closed source libraries from the likes of Google and others. Closed-source prevents me from adopting a new platform until the vendor gets around to porting it, and only if it fits with their strategy. Also a middleware-only company is liable to be bought out, and then closed. Example: Parse.
Edit: Apparently not the guts of it, my bad :(
I see references to a “core” in the code, what is that?
The core is referring to our internal C++ storage engine. It is not currently open-source but we do plan on open-sourcing it also under the Apache 2.0 license once we’ve had a chance to clean it up, rename it, and finalize major features inside of it. In the meantime, its binary releases are made available under the Realm Core (TightDB) Binary License.
Even just announcing the work of the Xamarin C# team that I'm on got some complaints from the public about this representing a "loss of focus". So yes, you could say there was a "business reason" of protecting the core team whilst they got to 1.0.
If you look at the C++ portions included in most of the Realm open source you can see we have moved code gradually into the open source codebase. There's not yet an official C++ API either for the same reason - it would lock in too many decisions and tie up the team.
(disclaimer - these are opinions and observations from a remote contractor, not Realm management!)
+1 for not just telling us what Realm is, but for showing us (with inline code), and for supporting React Native :)
> This repository holds the source code for the Java version of Realm, which currently runs only on Android.
I'm interested in trying this on the desktop (windows/linux/mac), but that doesn't seem possible? Wonder what makes it android only.
I'll let someone else clarify why Java outside Android isn't supported.
My complaints are as follows:
- No enum support
- No inheritance support
- Many LINQ operations aren't implemented, no select, no aggregate, etc. I have to do a ToList or ToArray to use these operations.
And that was just what came up in the first day of usage...
Why would I use Realm if EF7 gets SQLite Code First+Xamarin support and can do all of these things? Sure, it's faster, but faster doesn't matter if I'm not speed critical on my DB (most mobile apps aren't) and I can write cleaner code. It might be better than manually writing SQL queries, but it's a lot worse than existing ORM solutions.
Your complaints are noted and are more or less all in the pipeline. Our goal is definitely that you should be able to write cleaner as well as faster code than you would with EF. Thank you for your feedback!
1) When I see that a library has a note about threading, I generally expect that it will either be "its thread safe" or "these operations are not thread safe and you need your own synchronization." I think having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning.
2) My use case was reasonably simple - background thread A listens for messages about some expensive work to do, it updates the UI thread with the work, and then it spawns thread B to do that expensive work and keeps listening, thread B updates the worklist on the UI thread on completion. Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. Traditionally, I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render.
Maybe I misunderstood it, or there is some really simple architecture to handle this issue, but that is how it seemed to me from the documentation.
Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another.
On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level.
We have some designs in mind to allow scoping around passing objects between threads (see #3136), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future.
About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs and share how you think it could be improved.
Good point that we should be more explicit about threading model of Realm and its benefits.
Realms and their objects can be shared across threads (and processes), you just have to be explicit about it (by having each thread get its own instances of the given objects/realms). The huge benefit you get from this, is that you never have to worry about locking or any other concurrency issues. All threads will always have a consistent view of the data, it will only update to reflect changes done by other threads at safe points in your code (like between events, where you are not in the process of using the data).
> Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread.
You don't need 3 copies, only three instances. That way each thread will have its own instance (and as such not be affected by changes on other threads), but they will all point to the same underlying data.
> I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render.
With realm you don't even have to do that. You can let thread B modify the object, and then the UI thread can just watch its own instance of that same object and be notified when it changes, it can then update the UI. All perfectly safe without any need for manual synchronization between the threads.
Any chance Realm will or does support geospatial data? Couldn't find any indication that it does currently, so if I ever returned to this project then I'd likely suck it up and try to figure out why Spatialite corrupts larger datasets. But having an alternative would be nice.
We don't have a similar issue open for Realm Java, so it would be great if you could create one and detail your needs so we can work to support it.
=> Why not use the terms "object database" or "OODBMS", then ?
2. "Realm supports Java, Objective-C, React Native, Swift and Xamarin."
3. What about Python ?
3. Python support is doable, but we are focusing 100% on mobile front-ends right now. We don’t even support using Realm from Java outside of Android, for example. Eventually we do want to add support for Python, Ruby, node.js, etc.
Is there any practical way to use Python for mobile apps? Realm is only targeting mobile platforms AFAIK.
Two approaches that seem to work (or to be promising) are Kivy (https://kivy.org/) for cross-platform and PyBee / VOC (http://pybee.org/voc/) for Android.
To answer your question, Realm blows away Core Data & straight up SQLite. The context management (or lack thereof) is wonderful. Going further, I have found the errors self-explanatory and easy to fix. Finally, nice job throwing an exception trying to start a write block in a write block -- this forces client programmer to really think about where their writes happen instead of blindly writing all the time (and inevitably running into a nested write).
Windows. Specifically, my current project is targeting Windows desktop (not WinRT/UWP) in addition to mobile platforms and Mac.
It just seems like an odd limitation - it's all bits!
Yes, it's all bits, but those bits matter :). The internal query engine is extremely optimized based on the layout of those bits, on a per-architecture basis.
Also, integers are adaptively bit-packed, so you shouldn't worry about the size of your integers, as Realm will intelligently use the appropriate widths.
I'd suggest continuing to use this computed property pattern and to keep track of #651 where we're tracking better support for this.
Also: text index and a way to "unmigrate" a database on iOS would be cool when developers are working on different branches at once, so they can restore their data when they have a different migration version in some container
Unless I'm missing something, what you're describing could easily be done by having the version number or branch in the Realm path, or whatever identifier you want. You should open an issue so we can explore that more.
Strings are indexed, but I think you're referring to something like "full text search"? That's on the roadmap.
I've expected it to cross 1.0 after 0.99 but it keeps going on to more than 0.101. So, congrats on finishing the milestone.
One request though: what about grouping functionality?
From what we see, we are generally faster than raw SQLite on all metrics except when doing batch inserts. This is primarily an API problem, because our low-level access is 200-300% faster than SQLite (which Kevin also mentions). It is something we are well aware of and plan to address quickly after 1.0: https://github.com/realm/realm-java/issues/1684
Our own numbers are here: http://www.slideshare.net/ChristianMelchior/realm-building-a... including a link to the code
How does Realm tackle data syncing between devices ?
I'm currently starting work on an iOS application which will display large lists of data which will be constantly updated on a background thread...
I wonder how Realm implements lazy-loading / faulting of off-screen items .. ?
All elements of Realm (queries, lists and even individual properties on objects) are lazy loaded. That is an intrinsic property of the zero-copy architecture where objects directly reflect what is in the underlying database.
Is react native going to be 1.0 shortly? Or is that not included in this release?
I didn't gain any understanding though of why they needed to be replaced and how Realm is different.
It certainly forces you to think about threading (which is a good thing IMO). I just responded to a similar comment, and there are always our docs on threading which I'd encourage you to read.
Jesus Christ, that was the very first line.
We detached this subthread from https://news.ycombinator.com/item?id=11769795 and marked it off-topic.
Most of the time you do a insert/update/view, something that a simple helper class would do well.
The linked article explicitly says it's not a wrapper around SQLite - what gave you that impression?
> Realm is not an ORM, and is not built on top of SQLite. Instead we’ve built a full database for mobile app developers, one that uses native objects that are dynamically mapped to a full, custom database engine (not just a key-value store)