Hi,
what is the maximum size the sqlite db associated with Core Data should reach?
I'm thinking of implementing some house keeping to avoid it grows too much.
Thanks
No limit that I'm aware of. But don't store things like images or other binary objects in your databases. Instead, store those somewhere in the documents folder in the app, and just keep paths to them in your database. For both database size considerations, and also for performance when querying (and loading rows from) the database.
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.
No limit that I'm aware of. But don't store things like images or other binary objects in your databases. Instead, store those somewhere in the documents folder in the app, and just keep paths to them in your database. For both database size considerations, and also for performance when querying (and loading rows from) the database.
Thanks for replying, I read that for images with size around Kb was ok.
I'm also wondering why not may talk about house keeping, ok the size is unlimited but if I'm using my app to cache images I guess at some point I don't want to fill all device storage.
Does it have to be implemented as a cache with last date access for a certain item, and clean if too old?
Besides, I'm trying to make sure the writing on storage is asyncronous, is ther a common pattern for writing on storage (or on Core Data)?
Thanks.
My personal rule of thumb is, it's never appropriate to store BLOBs in your database. I mean it's not like you can query against them, right? So all they do is increase the size of the database, the time it takes to retrieve a rowset from the database, and the size of the records in memory.
Of course, careful database design (moving BLOBs into their own table) can address two of these issues. But I think the better design decision would be to just keep the BLOBs on the filesystem instead (which the Core Data Programming Guide also recommends). Not only will your database scale much better, but deleting records will cause less fragmentation. It's easy to break out the BLOBs into filesystem objects. Just add an attribute to your entity of NSString type to hold the filename (likely just a bare name, or a partial subpath plus name, depending on your directory structure). And when you need to save a new image, generate a unique filename with CFUUIDCreate and CFUUIDCreateString.
As for managing your storage footprint, I suppose this depends on what your database (and app) are doing. There's no way to predict how much storage is too much. Are you just caching data that you don't mind throwing away at some point?
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.
My personal rule of thumb is, it's never appropriate to store BLOBs in your database. I mean it's not like you can query against them, right? So all they do is increase the size of the database, the time it takes to retrieve a rowset from the database, and the size of the records in memory.
Of course, careful database design (moving BLOBs into their own table) can address two of these issues. But I think the better design decision would be to just keep the BLOBs on the filesystem instead (which the Core Data Programming Guide also recommends). Not only will your database scale much better, but deleting records will cause less fragmentation. It's easy to break out the BLOBs into filesystem objects. Just add an attribute to your entity of NSString type to hold the filename (likely just a bare name, or a partial subpath plus name, depending on your directory structure). And when you need to save a new image, generate a unique filename with CFUUIDCreate and CFUUIDCreateString.
As for managing your storage footprint, I suppose this depends on what your database (and app) are doing. There's no way to predict how much storage is too much. Are you just caching data that you don't mind throwing away at some point?
Thanks for the detailed answer.
Yes I have blobs in their own table, it should work like a browser cache. So basically image url and binary data in a Transformable.
About the storage footprint, I just want to avoid it will grow too much, so delete less accessed images, probably same thing a browser would do in case of limited cache size, just wondering best practice there.
The big advantage to have blobs was to avoid having to sync the DB Table with the references and the filesystem, but I'm convinced it's not advised, even though I'm quite sure I read somewhere it was ok for small images (less than 1MB).
Maybe a little bit off-topic, but what if I want to save on db (and filesystem in case) from a separate Thread?
Syncing the record and the filesystem objects is actually easy; all you need to do is override prepareForDeletion in your NSManagedObject subclass, and inside there, delete your associated filesystem objects.
As for doing CoreData inserts from a separate thread, I've never done this. I believe, however, the answer is that it's totally fine as long as each thread has its own NSManagedObjectContext and also doesn't try to share NSManagedObjects from other threads.
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.
all you need to do is override prepareForDeletion in your NSManagedObject subclass, and inside there, delete your associated filesystem objects.
Sonuva... I swear I looked at this before, and decided it could be triggered in a condition such that the item was being removed from a context, not necessarily the store. But rereading things now, I'm not sure why I arrived at that conclusion. I've been doing things The Hard Way.
Sonuva... I swear I looked at this before, and decided it could be triggered in a condition such that the item was being removed from a context, not necessarily the store. But rereading things now, I'm not sure why I arrived at that conclusion. I've been doing things The Hard Way.
So, thanks!
LOL... isn't that the way it goes, sometimes?
I've felt completely comfortable with Core Data for quite a while now, but I wouldn't be surprised to find that there are things about it I'm also doing the hard way.
And to my recollection, I've never posted a dev question on these forums, but I sure have picked up a lot of good info here over the last few years, just from reading the threads!
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.
Maybe I'm off-topic but I wanted to ask best approach for using Core Data as a cache considering multi-threading.
For instance I will have a page with images from the web, so I'm retrieving them by their URLs, using NSOperation I can do that asynchronously but I want to check first on my DB and write on it (or disk) the retrieved image for future use.
What can be the best way to do that without blocking the UI (like when scrolling)?
I read something about multi thread access on DB but still not sure best way to do that for reading/writing in conjunction with async network download.
Thanks for any tips on that.
Core Data DB Size
Sonuva... I swear I looked at this before, and decided it could be triggered in a condition such that the item was being removed from a context, not necessarily the store. But rereading things now, I'm not sure why I arrived at that conclusion. I've been doing things The Hard Way.
Linear Mode
