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

11–20 of 37 posts

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

#11

Post by BoorishBears »

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…

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

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

#12

Post by andrewbarba »

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…

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

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

#13

Post by azinman2 »

andrewbarba wrote: post #12
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…

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.

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

#14

Post by lpga510 »

citruspi wrote: post #4
david-given wrote: post #2

The documentation links on the github page are broken; see http://realm.io to find out what it is. (AFAICT it's basically Firebase.)

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.

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

#15

Post by HodGreeley »

danbruc wrote: post #6

OT: What happened in the database space and why? In 2000 you would have had a hard time naming enough database systems to run out of fingers for counting. But in recent years database system seem to pop out of the ground like JavaScript frameworks. So what changed? Did the idea of a general purpose database system break because the usage scenarios became so diverse that we can no longer pretend that one size fits alm…

NoSQL databases arose in response to the growth and change in data use, driven largely by the web. Typical needs cited include scalability, availability, performance, and flexibility. Development has been going on for a long time.

I think most would agree there is no longer a one size fits all (or even most).

Realm (and I know someone will correct me if I'm wrong) started out as an on-device only replacement for relational-style dbs focused on ease-of-use and performance.

It's not the only one. Couchbase Mobile is a NoSQL stack that has an on-device db that's also easier to use, and has focused for many years on getting sync right (which is a hard problem).

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

#16

Post by HodGreeley »

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.

Have you looked at Couchbase? NoSQL on-device db, cross-platform for Android, iOS, native Java, and others. (I work for Couchbase.)

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

#18

Post by HodGreeley »

david-given wrote: post #2

The documentation links on the github page are broken; see http://realm.io to find out what it is. (AFAICT it's basically Firebase.)

I don't think of Realm as being at all like Firebase, except from a very high level. Realm isn't hosted, it's an object database, until recently didn't do sync, and more.

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

#19

Post by unsoundInput »

BoorishBears wrote: post #11
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…

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.

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

#20

Post by [deleted] »

BoorishBears wrote: post #11
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…

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

[deleted]
Post reply on HN