brmunk
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-...
> 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/
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.
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.
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!
On Swifts birthday – where do we go from here?
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.
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
Libraries: “the cause of, and solution to, all of Android’s Problems.”
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?
The next billion dollar company in Mobile
Now On Kickstarter, Tickle Makes Learning To Code Fun With Scratch
Please Give Edward Snowden His Medal of Freedom Already
How to use GitHub issues?
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.
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.