I'm using Realm for storage on an iOS app.
The user will be storing binary data inside it (NSData*), and optionally be able to delete certain records to recover space.
Apart from using writeCopyToPath and replacing the database, is there any other means of forcing a compactation operation?
Apart from using writeCopyToPath and replacing the database, is there any other means of forcing a compaction operation?
That's the only way Realm currently supports recovering "pre-allocated but no longer used" disk space.
Support for automatically compacting Realm files on launch is also something that Realm is tracking: https://github.com/realm/realm-cocoa/issues/3289
Related
I'm using CoreData as my local app storage manager.
Sometimes I save BLOB files (images, videos, etc) and I notice that the app size increases, which is expected.
My problem appears when I delete some data, but the app size doesn't change.
I've downloaded the app's container and noticed that the appname.sqlite and appname.sqlite-wal are still large.
Does anyone know why this is happening?
Note: I'm using CoreData with CloudKit with NSPersistentCloudKitContainer if that can help.
Under CoreData is a sqlite database. Sqlite's vacuum command documentation explains what is happening
https://www.sqlite.org/lang_vacuum.html
When content is deleted from an SQLite database, the content is not usually erased but rather the space used to hold the content is marked as being available for reuse.
You could try to connect to the underlying sqlite database and use vacuum directly on it.
How to VACUUM a Core Data SQLite db?
But, in your case, I'd follow #matt's suggestion of not using BLOBs this way.
I have database with some default content. How can I use iCloud to sync changes in database on different devices?
I know how sync devices if CoreData was empty first and I can migrate from external sqlite file to CoreData.
If you have an existing Core Data store and you want to add iCloud support, you'll need to transfer all of your existing data to a new data store and save the result. This is necessary because iCloud only generates transactions when you save changes-- so you need to effectively save changes for everything to jumpstart the syncing process.
In most cases you can do this in a single step by using NSPersistentStoreCoordinator's migratePersistentStore:toURL:options:withType:error:. Pass in the same iCloud options that you would use when calling addPersistentStoreWithType:configuration:URL:options:error:. Use this alternate approach only when moving from a non-iCloud data store to one that does use iCloud.
Also, beware of using iCloud with Core Data. It has not earned a reputation for reliability. Pay close attention to Apple's documentation and sample projects, and even then be prepared for it to just not work sometimes.
Just wanted to know if this is a good idea:
I want to use iCloud to sync data between different devices in my iOS app. It's just a list of small objects without connections. But storing this list in the key/value store won't work because it's space is restricted to 1 MB or so and the list might get bigger (not much, but could...). Core data seems like an overkill to me and there is also the problem of possible duplicates.
So I wonder if it makes sense to subclass UIDocument to handle the XML file. Every object has an ID, so merging different versions of the file should be no problem.
The choice of XML depends on the format of the data store (monolithic or transactions) and the volume of updates. If the entire file (1 MB+) is constantly being written to by your app (and hence sync'ed to iCloud) or if a small change causes the entire store to be sync'ed to iCloud then I would use Core Data. The advantage of core data is that only the transaction logs you require (or have changed) are synced.
I have managed objects that have image properties. Since storing large blobs in CoreData is a bad idea, I'm trying to use the built-in CoreData option "Store in External Record File" which you can see in the Data Model Inspector.
Despite enabling this option, I do not see any image data being stored externally. Judging by the size, it seems like they are still being saved in the sqlite file. What is the issue?
If your store type is NSSQLiteStoreType, your attribute is NSBinaryDataAttributeType. You have enabled setAllowsExternalBinaryDataStorage and your object data size is larger then approximately 1MB.
Objects that are smaller than 1MB are stored in the sqlite database.
Objects that are larger are just a reference to a external file.
You'll find the (external) files in a hidden sub-directory at the same location as the persistent store.
<path>/<database>.sqlite
<path>/<your_database>_SUPPORT/_EXTERNAL_DATA/
sqlite2 does not allow size of BLOB data to be more than 1MB,However sqlite 3 allows larger BLOB.First check out which version of sqlite u r using.
And if ur file is in MB's i would rather prefer them storing in local database instead.
I want to create an in memory data store with core data on the iphone in the following way:
The data of the store is saved to disk in an encrypted file (max size 400kb)
The encrypted file is loaded completly into memory and afterwards I will decrypt it so that I have some data array in memory
I want to tell the NSPersistentStoreCoordinator to use this data array which is the store I want to use.
At certain points in the code the current in memory data store will be copied to another data array, encrypted and stored to disk such that the data on disk corresponds always to the most recent version of the data.
I must do that because the data is sensitive user data that absolutly cannot be stored in a plain database.
In my app I already implemented a version where each property of the managed objects are encrypted, such that the sqlite database which is stored on disk contains only cryptic unreadable values. Unfortunatly it turned out to be too slow to encrypt an decrypt everything everytime on the fly.
First off: Is this possible?
Secondly: Might there be some things I need to pay attention to?
I'm not sure if this will be of any help to you but in iOS5 persistent stores now store data in an encrypted format on disk. This is also an option in iOS4. See the documentation.
For applications built for iOS 5.0 or later, persistent stores now store data by default in an encrypted format on disk. The default protection level prevents access to the data until after the user unlocks the device for the first time. You can change the protection level by assigning a custom value to the NSPersistentStoreFileProtectionKey key when configuring your persistent stores. For additional information about the data protection that are new in iOS 5.0, see “Data Protection Improvements.”