6 ms·

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 th

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?

ultramancool 10y ago
I've been trying Realm for Xamarin recently and I've got to say I'm pretty disappointed with it, compared to my previous experiences with EF. My complaints are as follows: - No enum support - No inheritance support - Many LINQ operations aren't implemented, no select, no aggregate, etc. I have to do a ToList or ToArray to use these operations. And that was just what came up in the first day of usage... Why would I use Realm if EF7 gets SQLite Code First+Xamarin support and can do all of these things? Sure, it's faster, but faster doesn't matter if I'm not speed critical on my DB (most mobile apps aren't) and I can write cleaner code. It might be better than manually writing SQL queries, but it's a lot worse than existing ORM solutions.
- kristiandupont 10y ago
  The Xamarin product is the youngest in the family (and, not officially 1.0 like the others) so we obviously have a lot to do still. :-) Your complaints are noted and are more or less all in the pipeline. Our goal is definitely that you should be able to write cleaner as well as faster code than you would with EF. Thank you for your feedback!
- brmunk 10y ago
  Xamarin has been highly requested, so we have tried to make it available as quickly as possible as a pre-1.0 version to get the proper input from developers like yourself as to what should be prioritized. Love to keep getting your feedback on github as well. Thanks!
fermigier 10y ago
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 not just state that you support "JavaScript" ? 3. What about Python ?
- mwcampbell 10y ago
  > 3. What about Python ? Is there any practical way to use Python for mobile apps? Realm is only targeting mobile platforms AFAIK.
  - timanglade 10y ago
    That’s exactly why we haven’t added Python support right away, but in due time we will support server-side platforms as well!
  - fermigier 10y ago
    Some people are active in this domain, see: https://www.python.org/community/sigs/current/mobile-sig/ https://www.python.org/community/sigs/current/mobile-sig/ and https://mail.python.org/pipermail/mobile-sig/ https://mail.python.org/pipermail/mobile-sig/ Two approaches that seem to work (or to be promising) are Kivy (https://kivy.org/ https://kivy.org/) for cross-platform and PyBee / VOC (http://pybee.org/voc/ http://pybee.org/voc/) for Android.
- timanglade 10y ago
  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 considerations too, in the OODBMS feels very dated as a term. 2. We don’t support JavaScript in general at the moment, only JavaScript that runs inside JavaScriptCore inside React Native. Otherwise, we lack the C++ APIs that we rely on to power the underlying storage engine. We are trying to add support for more JavaScript runtimes though. 3. Python support is doable, but we are focusing 100% on mobile front-ends right now. We don’t even support using Realm from Java outside of Android, for example. Eventually we do want to add support for Python, Ruby, node.js, etc.
oulipo 10y ago
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
- jpsim 10y ago
  (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 https://github.com/realm/realm-cocoa/issues/new [1]: https://github.com/realm/realm-cocoa/issues/3650 https://github.com/realm/realm-cocoa/issues/3650
mwcampbell 10y ago
> 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.
- rocky1138 10y ago
  Also Unity3d works really well with it using the SimpleSQL plugin.
- timanglade 10y ago
  We absolutely want to add this. It’s tracked here: https://github.com/realm/realm-dotnet/issues/509 https://github.com/realm/realm-dotnet/issues/509
chris_7 10y ago
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!
- jpsim 10y ago
  (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 https://github.com/realm/realm-cocoa/issues/651
  - chris_7 10y ago
    Oh, given the packing, is there any reason to use the property instead of just moving up a size?
    - jpsim 10y ago
      I'm not sure what you mean here. If you mean "why would I ever use Int8 or Int32, etc. if Int64 won't take up more space in the file" the answer would be memory considerations when you take that data out of the Realm... you should just use the size you need and you'll be ok.
joslin01 10y ago
I'd like inheritance / polymorphism. For example, would love to subclass `AppUser` from `User`. I realize it's on your backlog, but just figure I'd give it another +1. To answer your question, Realm blows away Core Data & straight up SQLite. The context management (or lack thereof) is wonderful. Going further, I have found the errors self-explanatory and easy to fix. Finally, nice job throwing an exception trying to start a write block in a write block -- this forces client programmer to really think about where their writes happen instead of blindly writing all the time (and inevitably running into a nested write).
ndarilek 10y ago
I'm looking for a good geospatial data store that works on mobile devices. Ran into an issue where Spatialite used to corrupt databases larger than 2GB on Android (as in, run md5sum on the database, open it read-only, run another md5sum, notice they've changed.) At the time when I investigated this, the Android support was scattered across both the initial project and a secondary build with a vendored Spatialite, it wasn't clear whose issue it was, and none of the projects seemed interested in claiming ownership or suggesting fixes. The whole experience left me a bit soured on Spatialite as a mobile geospatial data store if your intent was to, say, load large areas for offline navigation. Maybe it'd work better in the case where you're syncing up specific areas, but my interest was in prepopulating with specific datasets for large regions since I was often off-network and couldn't predict whether a dataset would run out in the middle of a dead zone. Any chance Realm will or does support geospatial data? Couldn't find any indication that it does currently, so if I ever returned to this project then I'd likely suck it up and try to figure out why Spatialite corrupts larger datasets. But having an alternative would be nice.
- bigfish24 10y ago
  (Adam from Realm) we don't offer support for geospatial data yet. An issue to track this was created for Realm Cocoa: https://github.com/realm/realm-cocoa/issues/2569 https://github.com/realm/realm-cocoa/issues/2569 We don't have a similar issue open for Realm Java, so it would be great if you could create one and detail your needs so we can work to support it.
- mwcampbell 10y ago
  This isn't Realm related, but Lucene has a spatial extension. And Lucene has been ported to Android. So maybe you could use that.
  - ndarilek 10y ago
    Huh, will definitely do that, and will also file an issue for Java support in Realm. Thanks.
jknightco 10y ago
Per property/per field listeners would make Realm perfect for us (especially w/ RxJava support). The product as it is currently is fantastic, but with the ability to do realmObject.observeProperty("propertyName").subscribe(propertyValue -> {}); my life would be complete.
ttcbj 10y ago
I tried Realm for an OS X desktop app a few months ago. I initially liked it, but was surprised when I discovered the threading requirements (one realm instance per thread, cannot pass realm-based objects across threads). 1) When I see that a library has a note about threading, I generally expect that it will either be "its thread safe" or "these operations are not thread safe and you need your own synchronization." I think having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. 2) My use case was reasonably simple - background thread A listens for messages about some expensive work to do, it updates the UI thread with the work, and then it spawns thread B to do that expensive work and keeps listening, thread B updates the worklist on the UI thread on completion. Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. Traditionally, I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. Maybe I misunderstood it, or there is some really simple architecture to handle this issue, but that is how it seemed to me from the documentation.
- jpsim 10y ago
  (JP from Realm here) Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another. On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level. We have some designs in mind to allow scoping around passing objects between threads (see #3136[0]), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future. About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs[1] and share how you think it could be improved. [0]: https://github.com/realm/realm-cocoa/issues/3136 https://github.com/realm/realm-cocoa/issues/3136 [1]: https://realm.io/docs/swift/latest#threading https://realm.io/docs/swift/latest#threading
- 10y ago

ultramancool 10y ago

I've been trying Realm for Xamarin recently and I've got to say I'm pretty disappointed with it, compared to my previous experiences with EF. My complaints are as follows: - No enum support - No inheritance support - Many LINQ operations aren't implemented, no select, no aggregate, etc. I have to do a ToList or ToArray to use these operations. And that was just what came up in the first day of usage... Why would I use Realm if EF7 gets SQLite Code First+Xamarin support and can do all of these things? Sure, it's faster, but faster doesn't matter if I'm not speed critical on my DB (most mobile apps aren't) and I can write cleaner code. It might be better than manually writing SQL queries, but it's a lot worse than existing ORM solutions.

kristiandupont 10y ago
The Xamarin product is the youngest in the family (and, not officially 1.0 like the others) so we obviously have a lot to do still. :-) Your complaints are noted and are more or less all in the pipeline. Our goal is definitely that you should be able to write cleaner as well as faster code than you would with EF. Thank you for your feedback!
brmunk 10y ago
Xamarin has been highly requested, so we have tried to make it available as quickly as possible as a pre-1.0 version to get the proper input from developers like yourself as to what should be prioritized. Love to keep getting your feedback on github as well. Thanks!

fermigier 10y ago

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 not just state that you support "JavaScript" ? 3. What about Python ?

mwcampbell 10y ago
> 3. What about Python ? Is there any practical way to use Python for mobile apps? Realm is only targeting mobile platforms AFAIK.
- timanglade 10y ago
  That’s exactly why we haven’t added Python support right away, but in due time we will support server-side platforms as well!
- fermigier 10y ago
  Some people are active in this domain, see: https://www.python.org/community/sigs/current/mobile-sig/ https://www.python.org/community/sigs/current/mobile-sig/ and https://mail.python.org/pipermail/mobile-sig/ https://mail.python.org/pipermail/mobile-sig/ Two approaches that seem to work (or to be promising) are Kivy (https://kivy.org/ https://kivy.org/) for cross-platform and PyBee / VOC (http://pybee.org/voc/ http://pybee.org/voc/) for Android.
timanglade 10y ago
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 considerations too, in the OODBMS feels very dated as a term. 2. We don’t support JavaScript in general at the moment, only JavaScript that runs inside JavaScriptCore inside React Native. Otherwise, we lack the C++ APIs that we rely on to power the underlying storage engine. We are trying to add support for more JavaScript runtimes though. 3. Python support is doable, but we are focusing 100% on mobile front-ends right now. We don’t even support using Realm from Java outside of Android, for example. Eventually we do want to add support for Python, Ruby, node.js, etc.

oulipo 10y ago

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

jpsim 10y ago
(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 https://github.com/realm/realm-cocoa/issues/new [1]: https://github.com/realm/realm-cocoa/issues/3650 https://github.com/realm/realm-cocoa/issues/3650

mwcampbell 10y ago

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

rocky1138 10y ago
Also Unity3d works really well with it using the SimpleSQL plugin.
timanglade 10y ago
We absolutely want to add this. It’s tracked here: https://github.com/realm/realm-dotnet/issues/509 https://github.com/realm/realm-dotnet/issues/509

chris_7 10y ago

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!

jpsim 10y ago
(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 https://github.com/realm/realm-cocoa/issues/651
- chris_7 10y ago
  Oh, given the packing, is there any reason to use the property instead of just moving up a size?
  - jpsim 10y ago
    I'm not sure what you mean here. If you mean "why would I ever use Int8 or Int32, etc. if Int64 won't take up more space in the file" the answer would be memory considerations when you take that data out of the Realm... you should just use the size you need and you'll be ok.

joslin01 10y ago

I'd like inheritance / polymorphism. For example, would love to subclass `AppUser` from `User`. I realize it's on your backlog, but just figure I'd give it another +1. To answer your question, Realm blows away Core Data & straight up SQLite. The context management (or lack thereof) is wonderful. Going further, I have found the errors self-explanatory and easy to fix. Finally, nice job throwing an exception trying to start a write block in a write block -- this forces client programmer to really think about where their writes happen instead of blindly writing all the time (and inevitably running into a nested write).

ndarilek 10y ago

I'm looking for a good geospatial data store that works on mobile devices. Ran into an issue where Spatialite used to corrupt databases larger than 2GB on Android (as in, run md5sum on the database, open it read-only, run another md5sum, notice they've changed.) At the time when I investigated this, the Android support was scattered across both the initial project and a secondary build with a vendored Spatialite, it wasn't clear whose issue it was, and none of the projects seemed interested in claiming ownership or suggesting fixes. The whole experience left me a bit soured on Spatialite as a mobile geospatial data store if your intent was to, say, load large areas for offline navigation. Maybe it'd work better in the case where you're syncing up specific areas, but my interest was in prepopulating with specific datasets for large regions since I was often off-network and couldn't predict whether a dataset would run out in the middle of a dead zone. Any chance Realm will or does support geospatial data? Couldn't find any indication that it does currently, so if I ever returned to this project then I'd likely suck it up and try to figure out why Spatialite corrupts larger datasets. But having an alternative would be nice.

bigfish24 10y ago
(Adam from Realm) we don't offer support for geospatial data yet. An issue to track this was created for Realm Cocoa: https://github.com/realm/realm-cocoa/issues/2569 https://github.com/realm/realm-cocoa/issues/2569 We don't have a similar issue open for Realm Java, so it would be great if you could create one and detail your needs so we can work to support it.
mwcampbell 10y ago
This isn't Realm related, but Lucene has a spatial extension. And Lucene has been ported to Android. So maybe you could use that.
- ndarilek 10y ago
  Huh, will definitely do that, and will also file an issue for Java support in Realm. Thanks.

jknightco 10y ago

Per property/per field listeners would make Realm perfect for us (especially w/ RxJava support). The product as it is currently is fantastic, but with the ability to do realmObject.observeProperty("propertyName").subscribe(propertyValue -> {}); my life would be complete.

ttcbj 10y ago

I tried Realm for an OS X desktop app a few months ago. I initially liked it, but was surprised when I discovered the threading requirements (one realm instance per thread, cannot pass realm-based objects across threads). 1) When I see that a library has a note about threading, I generally expect that it will either be "its thread safe" or "these operations are not thread safe and you need your own synchronization." I think having no ability to share realms/objects across threads is really unusual, and it would be better if the docs made that requirement clearer at the beginning. 2) My use case was reasonably simple - background thread A listens for messages about some expensive work to do, it updates the UI thread with the work, and then it spawns thread B to do that expensive work and keeps listening, thread B updates the worklist on the UI thread on completion. Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread. Traditionally, I would expect one in-memory copy, with the threads using synchronized methods to modify the data. Then, when thread B completes, it just updates its work item and then notifies the UI thread to re-render. Maybe I misunderstood it, or there is some really simple architecture to handle this issue, but that is how it seemed to me from the documentation.

jpsim 10y ago
(JP from Realm here) Realm's transactions are entirely ACID, and all transactions are thread safe. This means you can't get "faults" like you would in Core Data if one thread deletes an object being accessed in another. On the flip side of this, it makes it difficult to share mutable object graphs across threads, mostly because then you'd need to know which Realm and which object is at what version of the db. Realm's underlying db engine supports this, but it's difficult to expose/enforce at the API level. We have some designs in mind to allow scoping around passing objects between threads (see #3136[0]), and some other ideas for passing immutable Realms across threads, so you can expect to see some improvements there in the future. About improving our documentation around threading, we're always open to feedback. I'd appreciate if you could read through the "Threading" section of our docs[1] and share how you think it could be improved. [0]: https://github.com/realm/realm-cocoa/issues/3136 https://github.com/realm/realm-cocoa/issues/3136 [1]: https://realm.io/docs/swift/latest#threading https://realm.io/docs/swift/latest#threading
10y ago