brmunk

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.

You might find this article useful as well: https://realm.io/news/eventually-consistent-making-a-mobile-...

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?

Yes it is crashproof. Fully ACID.

Any other questions?

This article goes a bit more into the details of threading: https://realm.io/news/threading-deep-dive/ And this one more into the core design: https://realm.io/news/jp-simard-realm-core-database-engine/

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.

Absolutely right. Only one writer at a time (locally), but writers don't block readers of which you can have multiple due to the MVCC design.

You could try contacting realm.io - the worlds 2'nd most used database.

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.

Re. POCO support: We expect to support that going forward - you can follow the issue here: https://github.com/realm/realm-dotnet/issues/529.

Let us know if you have other questions or concerns! Github issues is a good place to suggest features or ask questions.

Thanks!

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.

With the just released support for annotation processing Kotlin is now working with e.g. Realm.

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.

/Brian from Realm

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.

Would that be useful?

Sure - terms are the same. Free for all!

Congrats! What's the main attraction compared to your competitors?

Would love to hear about good hints for using github issues - or where it fails for OSS?

Right now there is no specific integration into any BaaS.

A Realm database is just a (compact) file that you can send as you see fit. As most BaaS solutions has their own local storage and API it may not always make sense to integrate, except that you could easily store a small Realm file as a blob in any BaaS and transfer it remotely.

It will also really soon be possible to export some or all objects as json which you then again can send to remote services. That does however take up much more space/bandwidth compared to Realms compact data format, but could be needed if you want to persist remotely in another database format.

We will surely add some guides to address that need (and many others). In the coming time we would love to expand on the documentation and clarification so you can learn Realm as easily as possible. Feel free to ping us with anything needing specific attention in the support forum: https://groups.google.com/forum/#!forum/realm-users

As for the tradeoff, I guess that heavily depends on the specifics of your app. You are the only one who can judge that depending on your current app pain points, maturity and future needs.

Currently not as a specific one liner. It's super simple to do it yourself, but we will likely add that convenience method shortly.

The RealmBrowser (which can be found under /tools/ at the above source link) is already using Realm internally to show/edit any Realm file dynamically.

"You can achieve anything with almost any storage technology" - is actually being very generous to quite a few other technologies :-) One of the promising benefits of any technology that can make things run magnitudes faster, is actually that you can do totally new things you previous thought impossible.

Android is in the works! You can signup to be notified of progress : http://realm.us5.list-manage1.com/subscribe?u=2aab5198c2f56b...!

Will the fluent interface catch on now that Swift syntactically makes it nice to look at (as opposed to Objective-C)? Or will you still prefer a string in the old Predicate format?

Could be really cool with a description of how the undocumented ones were found?