I am trying to use Realm in my new project.
But am interested in:
I have 10k objects of MyType.
And I want to filter and display only most recent 10 of them.
Will all of them be moved to RAM to operate/filter them?
'realm.objects(MyType).filter(...)' - I'm just worried about 10k objects and their data would litter the app memory in case of query like above.
No? It's OK?
When you filter objects, your query is constructed in a C++ DSL, which is efficiently evaluated, bringing in some optimizations to run it fast depending on the concrete property types.
Accessor objects are instantiated by the binding lazily when you retrieve each object out of your results. So in your case only for the first 10 objects.
Related
I am storing list of contacts from Phone Addressbook locally in my project and for that I am using realm db, problem now I am getting is to fetch batch of contacts (like a pagination). So thinking to do it using limit query. But there is no example with LIMIT query with realm. Is there any alternative for this to do pagination in realm?
In the Realm swift's document site (https://realm.io/docs/swift/latest/), they said
Since queries in Realm are lazy, performing this sort of paginating behavior isn’t necessary at all, as Realm will only load objects from the results of the query once they are explicitly accessed.
If for UI-related or other implementation reasons you require a specific subset of objects from a query, it’s as simple as taking the Results object, and reading out only the objects you need.
So you just simple get it all and process what you need. Example from Document site
// Loop through the first 5 Dog objects
// restricting the number of objects read from disk
let dogs = try! Realm().objects(Dog.self)
for i in 0..<5 {
let dog = dogs[i]
// ...
}
You do not need to implement fetching batches on your own as Realm Swift Queries are lazily loaded. "All queries (including queries and property access) are lazy in Realm. Data is only read when the properties are accessed."
So your query is very fast but accessing the data itself isn't as fast as using an array.
I need to pass near about 1000-1500 objects from one controller to another. My concern is basically on the speed. Will it affect if i send list or result. Or should i pass predicate and query it again. Then access the list of the queried object.
To be more clear.
I have object named Chat, which has a list of media. Now i wanna pass that media. What would be the best practice for that.
Also sometimes i need to filter the media. I then convert that result to list by using reduce func.
If you're referring to Realm Results objects, then you don't need to worry about this. Objects stored in Results are only lazily loaded into memory when your code specifically requests them. As such, passing the Results object around won't incur any overhead.
That being said, if you then use the native Swift reduce function to create a filtered array from a Results object, that would become a problem. That operation will go through and force each item in Results to get lazily-loaded at once, which could lead to memory issues. If possible, you should instead try and perform that operation using the Realm filter() method to produce another Results object.
There are at least 2 main collection types used in Realm:
List
Results
The relevant description from the documentation on a Results object says:
Results is an auto-updating container type in Realm returned from
object queries.
Because I want my UITableView to respond to any changes on the Realm Object Server, I really think I want my UITableView to be backed by a Results object. In fact, I think I would always want a Results object to back my UI for this reason. This is only reinforced by the description of a List object in the documentation:
List is the container type in Realm used to define to-many
relationships.
Sure seems like a List is focused on data modeling... So, being new to Realm and just reading the API, I'm thinking the answer is to use the Results object, but the tutorial (Step 5) uses the List object while the RealmExamples sample code uses Results.
What am I missing? Should I be using List objects to back my UITableViews? If so, what are the reasons?
Short answer: use a List if one already exists that closely matches what you want to display in your table view, otherwise use a Results.
If the data represented by a List that's already stored in your Realm corresponds to what you want to display in your table view, you should certainly use that to back it. Lists have an interesting property in that they are implicitly ordered, which can sometimes be helpful, like in the tutorial you linked to above, where a user can reorder tasks.
Results contain the results of a query in Realm. Running this query typically has a higher runtime overhead than accessing a List, by how much depends on the complexity of the query and the number of items in the Realm.
That being said, mutating a List has performance implications too since it's writing to the file in an atomic fashion. So if this is something that will be changing frequently, a Results is likely a better fit.
You should use Results<> as the Results is auto updating to back your UITableView. List can be used to link child models in a Realm model. where as Results is used to query the Realm Objects and you should add a Realm Notification Token so you know when the Results are updated and take necessary action (reload table view etc.) Look here for realm notifications: https://realm.io/docs/swift/latest/#notifications
P.S. The data in that example is just static and no changes are observed
I am building an app with Objective-C and I would like to persist data. I am hesitating between NSKeyedArchiver and core Data. I am aware there are plenty of ressources about this on the web (including Objective-C best choice for saving data) but I am still doubtful about the one I should use. Here are the two things that make me wonder :
(1) I am assuming I will have around 1000-10000 objects to handle for a data volume of 1-10 Mb. I will do standard database queries on these objects. I would like to be able to load all these objects on launching and to save them from time to time -- a 1 second processing time for loading or saving would be fine by me.
(2) For the moment my model is rather intricate : for instance classA contains among other properties an array of classB which is itself formed by (among other) a property of type classC and a property of type classD. And class D itself contains properties of type classE.
Am I right to assume that (1) means that NSKeyedArchiver will still work fine and that (2) means that using core Data may not be very simple ? I have tried to look for cases where core Data was used with complex object graph structure like my case (2) on the web but haven't found that many ressources. This is for the moment what refrains me the most from using it.
The two things you identify both make me lean towards using CoreData rather than NSKeyedArchiver:
CoreData is well able to cope with 10,000 objects (if not considerably more), and it can support relatively straight-forward "database-like" queries of the data (sorting with NSSortDescriptors, filtering with NSPredicate). There are limitations on what can be achieved, but worst case you can load all the data into memory - which is what you would have to do with the NSKeyedArchiver solution.
Loading in sub-second times should be achievable (I've just tested with 10,000 objects, totalling 14Mb, in 0.17 secs in the simulator), particularly if you optimise to load only essential data initially, and let CoreData's faulting process bring in the additional data when necessary. Again, this will be better than NSKeyedArchiver.
Although most demos/tutorials opt for relatively straight forward data models (enough to demonstrate attributes and relationships), CoreData can cope with much more sophisticated data models. Below is a mock-up of the relationships that you describe, which took a few minutes to put together:
If you generate subclasses for all those entities, then traversing those relationships is simple (both forwards and backwards - inverse relationships are managed automatically for you). Again, there are limitations (CoreData does the SQL work for you, but in so doing it is less flexible than using a relational database directly).
Hope that helps.
What is the best way to use CoreData:
1 - The first time I load all items from the store in the array, in the future, when I have to get one item (or more,meet certain properties), I just do filtering array (filteredArrayUsingPredicate)
OR
2 - Every time when I need to get the items (one item or several or all items) I load those games all from the repository?
When I am asking what is the best way, I actually mean what is the most efficient and most common way (quickest response time)?
Use MagicalRecord library. It has convienience methods like:
MR_findAll
MR_findFirst
MR_findFirstByAttribute and many, many others.
Don't use data arrays, and don't use 3rd party libraries.
Rather, read up on NSFetchedResultsController and discover how simple and scalable core data can be.