Realm certainly has a schema - anything that made you think it doesn't?
It's ACID and Serializable.
It also has a query language. But as one of the core design principles is to be as native to the language and platform as possible, the query language takes different forms. In Java it's a fluent API, in Cocoa it's NSPredicates string based. And the JS string based is roughly identical to that as well.
It's absolutely designed to be offline first. I'm curious as to which limitations you see with that?
Operational Transform is used to resolve conflicts at the property level, so I would say it's much more fine-grained than most other systems that would overwrite entire objects. The specific resolution rules are very simple and intuitive and how to deal with custom needs are described here: https://realm.io/docs/realm-object-server/#conflict-resoluti....
There is ordered lists already and explicit counters are being exposed in the SDKs at the moment.
I couldn't, and still can't, find any documentation or "list of features" that mention schema support, query language or ACID semantics. The documentation is pretty sparse and disorganized.
(By query language I don't mean an opaque builder based on NSPredicates or whatever, I mean a query language, written as text, which is portable across clients.)
OT is great, but it doesn't have that until it's actually exposed. My pet use case is string edits, which absolutely need to be cleanly conflict-resolvable.
The inconvenience with offline-first is that by definition you're never operating on current data: You have to sync to a central server before the data is visible to others, and you're editing potentially stale data. The latency of inbound syncing is particularly dependent on the volume of changes being sent from upstream, which might require that a client, so as not to be overwhelmed with updates, subscribe to a very small subset of the entire dataset. For example, if you open up a UI that edits a single document, you might want to subscribe to changes to only that document, in order to update the UI in real time. I don't know if that's even possible with Realm, or if you can in fact run it in "classic client/server" (i.e. "online first") mode.
Why would you want a text-based query language if you are an idiomatic C# programmer? Every database product on that platform is queried through the standard LINQ syntax - that's why we implemented it that way.
It's ACID & Serializable. A write will block all other writes, but multiple reads can occur without overhead or blocking due to MVCC.
Reads are consistent within the runloop, but updates to your objects occurs when you start a write transaction, so you know you always work on the latest version of the data. Basically, you are in an implicit read transaction all the time, except when you are in a write transaction :-).
> So if I am doing x.first, x.second while the object is being updated in a second thread, will I get mixed state?
So no you will not get mixed state.
> Is database crash proof? If the phone runs out of battery while in write transaction, will the database get damaged?
Being from Realm, I might not be the right one to give you a balanced view, but I can at least try a bit:
One huge difference is that Parse is no longer developed by a company after Facebook abandoned it. It's been open sourced and its future is up to the community.
Another is very related to this article. Realm resolves all your conflicts automatically, the developer doesn't have to do that. That's even done more fine grained at the property level.
Realms focus on being an offline first database means that your data is always available locally.
Then there are subjective differences. Until the launch of the Realm Mobile Platform, Realm has not had a solution for syncing to a backend. We have a lot of users who have chosen to use Realm locally and Parse as the backend. I guess that's a testament to the local database features from Realm. But with the new syncing solution, that's no longer needed, and all the networking code can be forgotten.
I'm sure others can come up with pros for Parse, but if you are not already invested in Parse, I think most would recommend looking elsewhere due to the first point.
Really sorry to hear you had a bad experience! I assume you created an issue for it? If not I would love to hear more about it (bm at realm dot io), so we can get it fixed and hopefully get you back as a happy camper again at some point.
Obviously one of the main points of building the new sync solution (or any library really) is to give you much more time for building differentiating features rather than building basics yourself. Now granted there are other solutions for the pure local persistence, but not many - if any - that will do what the new Realm Mobile Platform will for solving sync.
But obviously the basics must be right and solid - so hope you will provide us with sufficient info so we can get any of your issues resolved.
You are absolutely right - the general problem is super hard.
But even solving a specific use-case is hard for most developers who haven't done it before. It just takes a ton of time, and you often get some details wrong. And when you think you nailed it, then new requirements turns up :-) The result is that many apps don't work very well offline.
That's why we have spent several man-years on making a general solution with sufficient flexibility to cover most use-cases. We want to enable all developers to be able to add offline first and real-time features without the hassle of reinventing the wheel every time.
Another reason that OT is hard is that it doesn't fall out of a generic proof; you have to prove that your particular instance of OT follows a mathematical equation. And there is no tooling to verify that (it can't be ensured by typical type checkers).
So people either rely on an OT implementation that is generic enough for their needs, or risk inconsistency or subtle bugs to chase after for years.
Other approaches such as CRDT or total order are not vulnerable to that problem, but they have other concerns (like read performance, garbage collection, or intent preservation).
This is an interesting point. We at Realm have actually spent significant time thinking about it, and it is absolutely true that there is no easy way to prove the correctness of a system using OT.
But it helps to understand the fundamental constraints - for example, that operations must be commutative. In our case, we have had the luxury of designing our own database system, which means we could pick the semantics that we knew would lend themselves well to operational transformation. We have also made an effort to reuse semantics at multiple levels, limiting the number of OT instances that we had to convince ourselves would work.
Then of course, and for me at least, formal arguments are not enough, which is why we have spent a remarkable amount of resources on testing the system, including guided fuzz testing. :-)
It's the same C++ core used in the other Realm SDKs that is wrapped in JavaScript. The same API as what has been available in the ReactNative SDK for a while.
Havn't been through all the videos yet! But this looks really promising - great format! Only problem I guess is I feel I have to really watch it - instead of just listening on a podcast while commuting :-)
Xamarin has been highly requested, so we have tried to make it available as quickly as possible as a pre-1.0 version to get the proper input from developers like yourself as to what should be prioritized. Love to keep getting your feedback on github as well. Thanks!
It also has a query language. But as one of the core design principles is to be as native to the language and platform as possible, the query language takes different forms. In Java it's a fluent API, in Cocoa it's NSPredicates string based. And the JS string based is roughly identical to that as well.
It's absolutely designed to be offline first. I'm curious as to which limitations you see with that?
Operational Transform is used to resolve conflicts at the property level, so I would say it's much more fine-grained than most other systems that would overwrite entire objects. The specific resolution rules are very simple and intuitive and how to deal with custom needs are described here: https://realm.io/docs/realm-object-server/#conflict-resoluti.... There is ordered lists already and explicit counters are being exposed in the SDKs at the moment.
You might find this article useful as well: https://realm.io/news/eventually-consistent-making-a-mobile-...