Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Realm is a mobile database: an alternative to SQLite and key-value stores

github.com

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#21

Post by pixelman32 »

azinman2 wrote: post #9

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…

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.

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#22

Post by cyberferret »

It would be really cool to see this working in Ionic/Cordova. I've played with Firebase and CouchDB (and also SQLite) in Ionic, so would be good to see how Realm could work in the same context.

Sometimes I just want a simple persistent on board storage mechanism for my mobile apps without all the problems that localStorage exhibits. I wonder if Realm could be a lightweight alternative?

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#23

Post by bigfish24 »

cyberferret wrote: post #22

It would be really cool to see this working in Ionic/Cordova. I've played with Firebase and CouchDB (and also SQLite) in Ionic, so would be good to see how Realm could work in the same context. Sometimes I just want a simple persistent on board storage mechanism for my mobile apps without all the problems that localStorage exhibits. I wonder if Realm could be a lightweight alternative?

There is unofficial Realm Cordova support being done by the community: https://github.com/airamrguez/cordova-plugin-realm

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#24

Post by bigfish24 »

azinman2 wrote: post #9

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…

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.

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#25

Post by bigfish24 »

akeruu wrote: post #10

I have dabbled a bit with it quite a few times and was quite happy about it, but my main issue is that AFAIK there is not "pure" Java API for Realm. It seems there have been attempts at removing Android dependencies but it seems they were never finished, meaning you can't have it running on desktop apps. This is (sadly) a showstopper for me.

Adam from Realm, thanks for the feedback. We do plan to offer a pure Java API, but it hasn't been a top priority. However, with the launch of Realm Mobile Platform we have been getting more requests for this because teams want to use Java vs. Node on the server-side to build integrations. My best guess would be Q3 or Q4 of this year, since we still have higher priority features to work on.

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#26

Post by bigfish24 »

lpga510 wrote: post #14
citruspi wrote: post #4

Earlier quoted context omitted.

There are two products - Realm Mobile Database[0] and Realm Mobile Platform[1]. The former is, as the HN post suggests, basically a database for mobile applications which you can use in place of SQLite or as a key value store. The latter combines the database software which runs on the mobile devices with the Realm Object Server[2] which runs server side to provide something like Firebase (disclaimer: I've used the M…

What are the differences with firebase? There must be something.

The biggest would be the Realm Mobile Platform is not a service, but a server-side application, Realm Object Server, that you can run on your own alongside the mobile client SDKs embedded in your apps. Another key difference, is that with our Node.js SDK you can create a level of integration with any existing backend infrastructure that would be harder with Firebase.

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#27

Post by azinman2 »

bigfish24 wrote: post #24
azinman2 wrote: post #9

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…

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?

Re: Realm is a mobile database: an alternative to SQLite and key-value stores

#28

Post by bigfish24 »

azinman2 wrote: post #27
bigfish24 wrote: post #24

Earlier quoted context omitted.

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: Realm is a mobile database: an alternative to SQLite and key-value stores

#30

Post by BoorishBears »

pixelman32 wrote: post #21
azinman2 wrote: post #9

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…

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.…

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...
Post reply on HN