Live data from Hacker News

Realm 1.0

realm.io

41–50 of 112 posts

Re: Realm 1.0

#41
post #35

In order to use this, you have to have know SQLite, given that, why would I spend time to learn something that wraps around it? Most of the time you do a insert/update/view, something that a simple helper class would do well.

> In order to use this, you have to have know SQLite, given that, why would I spend time to learn something that wraps around it?

The linked article explicitly says it's not a wrapper around SQLite - what gave you that impression?

> Realm is not an ORM, and is not built on top of SQLite. Instead we’ve built a full database for mobile app developers, one that uses native objects that are dynamically mapped to a full, custom database engine (not just a key-value store)

Re: Realm 1.0

#42

Earlier quoted context omitted.

1. "Realm is not an ORM, and is not built on top of SQLite. Instead we’ve built a full database for mobile app developers, one that uses native objects that are dynamically mapped to a full, custom database engine (not just a key-value store)." => Why not use the terms "object database" or "OODBMS", then ? 2. "Realm supports Java, Objective-C, React Native, Swift and Xamarin." => "React Native" is not a language, why…

1. We are close to an object database, but with some subtle distinctions from the mainline expectations I believe — data is serialized in a language-independent binary format, that is actually column-oriented. We also have full indexing available of all fields. It’s not that object databases can’t do that, it’s just that most people probably don’t expect that level of access. And to be honest, there are marketing con…

Looking forward to Cordova/Ionic support, our community would love this (I see it's slated already, cool).

Re: Realm 1.0

#43
post #37

Please don't say it is faster than SQLite anymore. http://kpgalligan.tumblr.com/post/133281929963/my-talk-at-dr...

With all respect to Kevins benchmarks. There are many ways to measure performance and most of them are wrong. If you see the talk he even admit that his numbers changed quite a bit between each benchmark run.

From what we see, we are generally faster than raw SQLite on all metrics except when doing batch inserts. This is primarily an API problem, because our low-level access is 200-300% faster than SQLite (which Kevin also mentions). It is something we are well aware of and plan to address quickly after 1.0: https://github.com/realm/realm-java/issues/1684

Our own numbers are here: http://www.slideshare.net/ChristianMelchior/realm-building-a... including a link to the code

Re: Realm 1.0

#45
Congrats on the release, glad you made it to 1.0. And well done sticking to semantic versioning and going to 0.100 before doing the 1.0.

Re: Realm 1.0

#46
post #29

VP Product at Realm here. Thanks to everyone on HN for the support over the years! We came out of YC in Summer 11 and it’s been a fantastic ride growing over the past few years. Would love to hear y’alls thoughts on what we should add next. Is there any reason why you’d still use SQLite?

Is unsigned integer support coming any time soon? Right now I'm using an integer and a computed property (Swift) to reinterpret the bit pattern as an unsigned value, which is... okay, I guess, as the field doesn't ever need to be queried. Filesize really matters in my case, so I don't want to go up an integer size. It just seems like an odd limitation - it's all bits!

(JP from Realm here)

Yes, it's all bits, but those bits matter :). The internal query engine is extremely optimized based on the layout of those bits, on a per-architecture basis.

Also, integers are adaptively bit-packed, so you shouldn't worry about the size of your integers, as Realm will intelligently use the appropriate widths.

I'd suggest continuing to use this computed property pattern and to keep track of #651[0] where we're tracking better support for this.

[0]: https://github.com/realm/realm-cocoa/issues/651

Re: Realm 1.0

#47

VP Product at Realm here. Thanks to everyone on HN for the support over the years! We came out of YC in Summer 11 and it’s been a fantastic ride growing over the past few years. Would love to hear y’alls thoughts on what we should add next. Is there any reason why you’d still use SQLite?

> Is there any reason why you’d still use SQLite? Windows. Specifically, my current project is targeting Windows desktop (not WinRT/UWP) in addition to mobile platforms and Mac.

Also Unity3d works really well with it using the SimpleSQL plugin.

Re: Realm 1.0

#48
post #26

VP Product at Realm here. Thanks to everyone on HN for the support over the years! We came out of YC in Summer 11 and it’s been a fantastic ride growing over the past few years. Would love to hear y’alls thoughts on what we should add next. Is there any reason why you’d still use SQLite?

R-tree :) Also: text index and a way to "unmigrate" a database on iOS would be cool when developers are working on different branches at once, so they can restore their data when they have a different migration version in some container

(JP from Realm here)

Unless I'm missing something, what you're describing could easily be done by having the version number or branch in the Realm path, or whatever identifier you want. You should open an issue[0] so we can explore that more.

Strings are indexed, but I think you're referring to something like "full text search"? That's on the roadmap[1].

[0]: https://github.com/realm/realm-cocoa/issues/new [1]: https://github.com/realm/realm-cocoa/issues/3650

Re: Realm 1.0

#49
post #37

Please don't say it is faster than SQLite anymore. http://kpgalligan.tumblr.com/post/133281929963/my-talk-at-dr...

It's worse than just that. They claim it's a "replacement" (!) for SQLite. That is an incredibly bold claim. From what I've gathered about Realm it isn't the same type of database as SQLite at all: Object store versus relational tables.
Post reply on HN