Live data from Hacker News

Show HN: Realm (YC S11), a mobile database

realm.io

101–105 of 105 posts

Re: Show HN: Realm (YC S11), a mobile database

#101
post #100

Earlier quoted context omitted.

Thanks for the feedback, benchmarks are notoriously difficult to get accurate (and fair), which is exactly why we published the benchmark code. We will incorporate your feedback to improve them.

I'm a little late to the party, but I ran the benchmark inserts with cached statements on both my Macbook Pro and my iPhone 5S. sqlite definitely fairs better under this scenario. That being said I still find the speed of Realm pretty impressive. And it's hard to gauge real world performance from this test. In my experience the real bottle necks around insert are upsets and establishing maintaining relationships. For…

That's pretty cool, and roughly what I saw in my emulator - maybe my fumbling actually did it right :) And very much agreed, Realm is pretty impressive, and micro-benchmarks like this aren't all that useful.

Have you set up a pull request / issue by any chance? It paints Realm in a bit worse of a light, but hopefully they'll merge it in and update the site.

Re: Show HN: Realm (YC S11), a mobile database

#102
post #41

I could do with some clarification on what problem the product solves, and actually, what the product even is. To me this looks like a new DB, and an ORM style interface to interact with it? I like that it is multi-platform, but SQLLite is a pretty mature DB store available on all the major platforms anyway. I get that it is faster... but presumably there are there trade-offs for this speed gain. I would like a bette…

Absolutely. There’s a lot more details in our launch blogpost [0], but you got the right impression: it’s a custom C++ storage engine underneath (not SQLite), that is tightly integrated with the object layer. Not an ORM per se, because the engine isn’t relational, and because there’s not copying/mapping/translation going on — the data on disk is the same data you manipulate in your language. The big problems we try t…

Although I don't know exactly what the implications are just yet, I've created a category on one of my RLMObject subclasses which accepts an NSArray or NSDictionary property and in the getter/setter converts to and from the NSData backing property. The only thing is after [Venue creatInDefaultRealmWithObject:] I have to explicity set the value for it to propogate to the backing NSData property.

It's extra work, but it lets me manipulate Realm into doing what I want it to do to store data which doesn't conform to an explicit schema. (e.g. a Venue which has an array of address strings, where I don't want the headache of iterating through venue.address[i].string values:

(note: this doesn't look pretty, its doing some funky formatting!)

"venue" : { "name":"Test Venue", "address" : [ "address line 1", "address line 2", "address line 3 for rare instances" ] }

@interface Venue : RLMObject @property NSString name; @property NSData addressData; @end

@interface Venue (AddressToData) @property NSArray address; @end

+ (NSDictionary )defaultPropertyValues { return @{ @"addressData":[NSJSONSerialization dataWithJSONObject:@[] options:0 error:nil] }; }

- (NSArray) address { NSArray address = nil;

    if (self.addressData) {
        address = [NSJSONSerialization JSONObjectWithData:self.addressData options:0 error:nil];
    } else {
        address = @[];
    }
        
    return address;
}

- (void) setAddress:(NSArray )address { if (!address) { address = @[]; }

    NSData *data = [NSJSONSerialization dataWithJSONObject:address options:0 error:nil];
    
    self.addressData = data;
}

Re: Show HN: Realm (YC S11), a mobile database

#103

Earlier quoted context omitted.

Absolutely. There’s a lot more details in our launch blogpost [0], but you got the right impression: it’s a custom C++ storage engine underneath (not SQLite), that is tightly integrated with the object layer. Not an ORM per se, because the engine isn’t relational, and because there’s not copying/mapping/translation going on — the data on disk is the same data you manipulate in your language. The big problems we try t…

Although I don't know exactly what the implications are just yet, I've created a category on one of my RLMObject subclasses which accepts an NSArray or NSDictionary property and in the getter/setter converts to and from the NSData backing property. The only thing is after [Venue creatInDefaultRealmWithObject:] I have to explicity set the value for it to propogate to the backing NSData property. It's extra work, but i…

    RLMRealm *realm = [RLMRealm defaultRealm];
    [realm beginWriteTransaction];
    
    for (NSDictionary *v in json[@"venues"]) {
        Venue *venue = [Venue createInDefaultRealmWithObject:v];
        NSArray *address = v[@"address"];
        venue.address = address;
    }
    
    [realm commitWriteTransaction];

Re: Show HN: Realm (YC S11), a mobile database

#104
post #101
post #100

Earlier quoted context omitted.

I'm a little late to the party, but I ran the benchmark inserts with cached statements on both my Macbook Pro and my iPhone 5S. sqlite definitely fairs better under this scenario. That being said I still find the speed of Realm pretty impressive. And it's hard to gauge real world performance from this test. In my experience the real bottle necks around insert are upsets and establishing maintaining relationships. For…

That's pretty cool, and roughly what I saw in my emulator - maybe my fumbling actually did it right :) And very much agreed, Realm is pretty impressive, and micro-benchmarks like this aren't all that useful. Have you set up a pull request / issue by any chance? It paints Realm in a bit worse of a light, but hopefully they'll merge it in and update the site.

I didn't see the benchmark code in the repo, so I didn't really think about a pull request. Next time I find time I'll poke around a bit more. They are trivial changes though.
Post reply on HN