101–110 of 112 posts
I'm currently starting work on an iOS application which will display large lists of data which will be constantly updated on a background thread...
I wonder how Realm implements lazy-loading / faulting of off-screen items .. ?
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?
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."…
Good point that we should be more explicit about threading model of Realm and its benefits.
Realms and their objects can be shared across threads (and processes), you just have to be explicit about it (by having each thread get its own instances of the given objects/realms). The huge benefit you get from this, is that you never have to worry about locking or any other concurrency issues. All threads will always have a consistent view of the data, it will only update to reflect changes done by other threads at safe points in your code (like between events, where you are not in the process of using the data).
> Based on my understanding of realm, I was going to have 3 copies of each object, one on each thread.
You don't need 3 copies, only three instances. That way each thread will have its own instance (and as such not be affected by changes on other threads), but they will all point to the same underlying data.
> 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.
With realm you don't even have to do that. You can let thread B modify the object, and then the UI thread can just watch its own instance of that same object and be notified when it changes, it can then update the UI. All perfectly safe without any need for manual synchronization between the threads.
Does Realm support NSFetchedResultsController-like functionality ? I'm currently starting work on an iOS application which will display large lists of data which will be constantly updated on a background thread... I wonder how Realm implements lazy-loading / faulting of off-screen items .. ?
All elements of Realm (queries, lists and even individual properties on objects) are lazy loaded. That is an intrinsic property of the zero-copy architecture where objects directly reflect what is in the underlying database.
https://www.google.com/search?q=site%3Arealm.io%20durability...
Earlier quoted context omitted.
FAQ time: I see references to a “core” in the code, what is that? The core is referring to our internal C++ storage engine. It is not currently open-source but we do plan on open-sourcing it also under the Apache 2.0 license once we’ve had a chance to clean it up, rename it, and finalize major features inside of it. In the meantime, its binary releases are made available under the Realm Core (TightDB) Binary License.…
Ah, OK. I always assumed that the core was closed-source for business reasons.
Even just announcing the work of the Xamarin C# team that I'm on got some complaints from the public about this representing a "loss of focus". So yes, you could say there was a "business reason" of protecting the core team whilst they got to 1.0.
If you look at the C++ portions included in most of the Realm open source you can see we have moved code gradually into the open source codebase. There's not yet an official C++ API either for the same reason - it would lock in too many decisions and tie up the team. (disclaimer - these are opinions and observations from a remote contractor, not Realm management!)
Does Realm support NSFetchedResultsController-like functionality ? I'm currently starting work on an iOS application which will display large lists of data which will be constantly updated on a background thread... I wonder how Realm implements lazy-loading / faulting of off-screen items .. ?
Yes, see https://realm.io/docs/swift/latest/#collection-notifications for details on how you can watch query results for changes to update your TableViews. All elements of Realm (queries, lists and even individual properties on objects) are lazy loaded. That is an intrinsic property of the zero-copy architecture where objects directly reflect what is in the underlying database.
Earlier quoted context omitted.
What's the benefit of using realm instead of Sqlite + an ORM ?
Here are a couple we highlight: 1. Since Realm is not a relational database with an ORM, we don't run into the impedance mismatch. Relationships are first-class citizens. 2. Realm uses a zero-copy architecture. Objects and collections are lazy loaded offering benefits to both memory use and speed.
Will we see some NativeScript support?
Will we see some NativeScript support?
for react native, how does realm compare to relay?