Hacker News Reader

Comment by azinman2 | Hacker News Reader

I've had some nasty bugs happen in production with Realm, as is expected with any new database store. Newer version seem better in this regard, but if you read the changelogs you might be shocked at how fundamental the fixes can be.

It also times some time getting use to -- my biggest gripe is that the notification API won't tell you what actually has been modified, just that an object changed _somehow_. That makes a pure reactive design quite hard if those changes have non-trivial consequences, and not just a quick re-rendering of some element on the screen.

Looking forward to finding time to go back to SQLite where I can actually do complicated queries, relational joins, triggers, etc on a fast and mature code base.

View on HN

I've also experienced some production issues with Realm. I've been using it for an App Store mac app since before 1.0 (Quite risky, yes, but it's for a simple use case). In the worst cases, it caused data corruption for end users.

Over the past year, it's become a lot more stable and I've seen far fewer user reported issues with it. As others have pointed out, it's also a very nice API and very simple to get set up.

The Realm team has also been very helpful in my experience and usually have responded to my support requests almost immediately, despite the fact I'm using their free product and not the DB-as-a-service they recently shipped.

I wouldn't take exception to it's stability if they didn't call it ACID compliant. I was about to use it in a setting where failure to be ACID complaint would be fairly expensive (but not safety critical). In just 24hrs of testing I managed to end up with a corrupt DB. In the same tests SQLite's been running for almost a year without corruption...

SQLBrite adds reactivity to SQLite (https://github.com/square/sqlbrite)

But in general I rely on RxJava to provide fine grained notifications. For example (psudeocode):

    someUserQueryThatReturnsObservable()
      .map(user->user.firstName)
      .distinct()
      .subscribe(newFirstName->newFirstName)

It's messy because you end up having to repeat everything after map for every property, not really an ideal solution

I started using sqlbrite (in combination with sqldelight) and stopped treating the database as an object store. Instead I create an interface for the data the customer needs (e.g. an item interface for elements in a listview), write a select query whose result fulfills this interface, and let the rest happen via databinding. This seems to work fine up to a couple of thousand of elements for me.

I am assuming this is coming from an Android point of view? If not, we do support passing what changed in the notifications for all the other platforms now. We call it "collection notifications" for example with JS: https://realm.io/docs/javascript/latest/#collection-notifica...

Android support is coming in a matter of weeks, so stay tuned.

I'm on iOS and I haven't upgraded to the latest as we're still on swift 2.3.

The docs you sent me seem to suggest that it's still just indices for objects modified. Where are the property changes?

Property changes are only supported with individual object notifications that were introduced with Realm 2.4. We haven't planned to add property changes in the collection notifications yet, but will definitely note the request!

Re: your gripe, this is solved in their latest release with object-level notifications: https://realm.io/news/realm-objc-swift-2.4/

I personally think they did an awesome job with the change api

Except that's on an individual object -- existing KVO functionality re-invented. I want it on an entire collection... basically their existing API except give me more than an index.

Reply on news.ycombinator.com