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.
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.
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!
Realm itself only adds less than 1 MB extra in your final app :-)
On Xamarin.iOS the Realm static libraries for all the iOS platforms and architectures we support are embedded inside the Realm.dll assembly. During build, Xamarin extracts the static libraries and links the app against them.
We should be more explicit about the size implications to avoid that chocking misunderstanding! We will update our FAQ.
Not out of the box at the moment. But it would technically be possible to do. Feel free to post a suggestion to https://github.com/realm/realm-js/issues so we can see the interest.
I'm not sure I can make it justice in a few words :-) But shortly:
The core has been developed from the ground up in C++ over the last 3 1/2 years. Realm’s efficiency comes from leveraging bit-packing, caching, vectorization, query algorithm innovations and a zero-copy architecture to realize gains in memory usage and speed. Data is stored in a single memory mapped file. It uses copy-on-write MVCC (Multi-Version-Concurrency-Control) allowing very efficient fully ACID serializable transactions.
The core is exceptionally fast, which we can leverage to make easy to use API's in the different languages (currently Java, ObjC, Swift and more to follow) and still maintain a speed and functionality advantage.
Yeah we absolutely have a lot of work ahead of us (as mentioned in the post). And the issues you mention are tracked in https://github.com/realm/realm-java/issues. There you can also see that we got a lot more features we want to add than the few you mention :-) We strive to be very transparent about our limitations (http://realm.io/docs/java/0.80.0/#current-limitations) so that they at least don't surprise anyone.
We seriously love to get the feedback so we can prioritize the additional features our users desire the most.
That said, we are very encouraged to see that the current features satisfy a lot of "non-toy" apps as well and that many thousands developers are building new apps every week.
You can see some of them mentioned here: http://realm.io/users/, and at the end of that page is also some unedited interviews with developers.
Hi, Brian from Realm here.
Surely hard to find much info about the internals yet. We could and should absolutely share more about that in a blog post. And to be honest we have for a long time wanted to do that, but just prioritized to enhance the features and support people building apps. We will get back on that.
Absolutely - it's a totally new C++ fast nosql fully ACID database underneath. The database has been in development for the past 3 years, so it's not just a quick hack :-)
Absolutely! That's actually already there. Even with nice expression based query syntax - looks like natural language :-) We havn't released it though since we plan to rewamp it into a more object oriented interface like in ObjC, Swift and Java. But if you really wanted to, nothing prevents you from using it (the .h files are there), except there is little documentation and the API will likely change.
But yes, definitely it will come fully supported.
The nice thing is you can then make have e.g. common C++ code shared between your mobile app platforms (as quite a few do), and share state/data easily between C++ & Java or C++ & ObjC/Swift in one app. No fuss, one API, one shared datamodel, fully threadsafe between languages.
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-...