Save part of Core Data into the cloud - ios

Working on iOS 7, I have to debug an application using Core Data with several entities. First I was asking for adding iCloud (and not cloud kit) to save all the data. But then, the client realized he wanted to save only some entities but not all of them into the cloud.
Is it something possible ? Do I need to use several NSPersistentStoreCoordinator ? (the application already use several NSManagedObjectContext, one per entity). Or maybe I can do something when I receive the notification :
NSPersistentStoreDidImportUbiquitousContentChangesNotification
and manually perform the merge but I really don't know how.
Thanks for your help.
Thanks to Tom Harrington, I created 2 configurations: CloudConfiguration and LocalConfiguration and I add some entities in each (this link helps me too).
Then, I add persistent store in the coordinator:
// Configure persistentStoreCoordinator
NSError* error1 = nil;
NSString *cloudConfiguration = #"CloudConfiguration";
NSPersistentStore *store1 = [_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"CloudConfiguration"
URL:[self storeURLForConfiguration:cloudConfiguration]
options:#{ NSPersistentStoreUbiquitousContentNameKey : #"iCloudStore" }
error:&error1];
if (error1) {
NSLog(#"Error: %# \n Description : %# \nUser info : %#", error1, error1.description, error1.userInfo);
}
NSLog(#"*************** cloud store url ************** : %#", store1.URL);
NSError* error2 = nil;
NSString *localConfiguration = #"LocalConfiguration";
NSPersistentStore *localStore = [_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:localConfiguration
URL:[self storeURLForConfiguration:localConfiguration]
options:nil
error:&error2];
if (error2) {
NSLog(#"Error: %# \n Description : %# \nUser info : %#", error2, error2.description, error2.userInfo);
}
NSLog(#"*************** local store url ************** : %#", localStore.URL);
All of my entities goes in one store only (cloud or local). Entities in different store don't have any relationship and I have a single model.
So here I go, I start my app for the first time all seems to be well configured. But when I try on another device or on the same device after deleting the app, I have a crash, just after getting : Using local storage: 0.
Here is the crash log :
[_PFUbiquityRecordImportOperation main](734): CoreData: Ubiquity: Error importing transaction log: <PFUbiquityTransactionLog: 0x16ed7f50>
transactionLogLocation: <PFUbiquityLocation: 0x16ed7ee0>: /var/mobile/Library/Mobile Documents/6ULEJ9RYTQ~fr~company~iCloudTestApp/CoreData/iCloudStore/mobile~E722813A-96E8-4E11-8DDE-56FF3837DEBD/iCloudStore/EU31J4aJIvvEyVMcWWYs1qgVajMk4_4fQxw1oe_Q0i0=/4C6B58B3-6C8D-4393-9B1E-8E48C7352091.1.cdt
transactionNumber: 1, exception: Invalid parameter value (bad entity)
User Info: (null)
2014-12-02 12:35:34.837 iCloudTestApp[1421:3b0b] -[_PFUbiquityRecordsImporter discoverAndImportAllAvailableLogs:error:](727): CoreData: Ubiquity: Exception while scanning for logs to import: Invalid parameter value (bad entity)
userInfo: (null)
It sounds weird to me because it's happen before the merge. Of course, I remove all the datas in the cloud before testing with those two configurations. If you have any idea...

Not multiple persistent store coordinators, but multiple persistent store files. You can add multiple persistent stores to the same coordinator by calling addPersistentStoreWithType:configuration:URL:options:error: multiple times. You don't have to use the same options every time, so you can use iCloud options for one store file but leave them out for a different one.
But you need to be aware of a couple of things:
You can't create relationships between objects in different persistent store files. If that's a problem, look into fetched properties. They're properties that transparently fetch objects using a predicate that you provide. They work sort of like one-way relationships.
You need some way to tell Core Data which store file to use for new objects. There are a couple of ways to do this:
If some of your entities could go in either persistent store, you'll need to use [NSManagedObjectContext assignObject:toPersistentStore:] every time you create a new instance.
For entities that will always be in the same store file, look into "configurations" for your model file. This lets you create named subsets of your model that contain only some of the entities. Use the configuration name when you add the persistent store file. Then, all new instances of those entities will automatically go to the right file.
Additional, based on updated question:
If you already have iCloud data that you need to use, you can't just switch to using configurations. The existing iCloud transaction logs may contain references to entities that are not in your new iCloud-only configuration. When it tries to import that data, it will fail, and you'll get errors like the one you're seeing.
If this app is still in development, I'd say just delete all existing iCloud data and go with the configuration. If you need to keep the existing iCloud data, you must ensure that all entities in the current iCloud data are still available. That most likely means you'll have to do without configurations and instead assign objects to one store or the other in your code.

Related

Core Data - Lightweight migration doesn't work

I am new to Core Data, and I am currently maintaining an application using Core Data.
In the need of publishing a new release of the application soon, I have to add en Entity to the data model.
I have followed this tutorial Lightweight tutorial which was very useful but also I have read all the Apple documentation but also this amazing article Core Data Migration in order to understand globaly how it works.
Although I had to add only one entity to the data model, I heard that a Lightweight migration was OK in this situation.
It's only 1 new Entity (without attributes) that I have to link to the already existing parent Entity.
What I have done so far :
The application is currently on the version 3 of the datamodel
I have created a new data model (version 4) from the version 3
I have chosen data model version 4 as current data model
I have created my new Entity (whithout attribute), and linked it to the parent Entity.
I have created the generated class object
Then I modified my UI
Build and run, it works, cool. BUT when I download the current version from the AppStore, and when I install the new recently made Archive/IPA from TestFlight, (install over the old one -> migration scenario) the Application run without my new Entity/Datamodel.
From the Apple documentation, it is very clear that adding Entity is supported by Core Dara for Lightweight Migration.
I know this is not an easy process, but I feel like I have followed everything perfectly.
How can I test the migration without each time archive, publish on TestFlight etc...
If you need any additional informations in order to clearly understand my issue and/or write a more elaborated answer, feel free to ask in the comment and I will edit my question.
Thank you in advance.
EDIT :
Here are the code about the NSPersistentStoreCoordinator from the AppDelegate.
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator {
// The persistent store coordinator for the application. This implementation creates and return a coordinator, having added the store for the application to it.
if (_persistentStoreCoordinator != nil) {
return _persistentStoreCoordinator;
}
// Create the coordinator and store
_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
NSURL *storeURL = [self persistentStoreURL];
NSError *error = nil;
NSString *failureReason = #"There was an error creating or loading the application's saved data.";
if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:#{NSMigratePersistentStoresAutomaticallyOption:#YES, NSInferMappingModelAutomaticallyOption:#YES} error:&error]) {
// Report any error we got.
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
dict[NSLocalizedDescriptionKey] = #"Failed to initialize the application's saved data";
dict[NSLocalizedFailureReasonErrorKey] = failureReason;
dict[NSUnderlyingErrorKey] = error;
error = [NSError errorWithDomain:#"YOUR_ERROR_DOMAIN" code:9999 userInfo:dict];
// Replace this with code to handle the error appropriately.
// abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
DDLogError(#"Unresolved error %#, %#", error, [error userInfo]);
abort();
}
return _persistentStoreCoordinator;
}
I don't know how can I effectively know by tests or logs that CoreData use the new data model (version 4) and has performed the migration successfully.
I know it works when I build from xCode but it's not the same situation than an update from the AppStore.
To set up an app for a lightweight migration, you need to insert the following lines into your CoreData framework where the Persistent Store is declared. These settings enable the options that support lightweight migrations (these are from a Swift 3.0 app so they may vary a bit if you're in 2.3):
NSMigratePersistentStoresAutomaticallyOption as NSObject: true
NSInferMappingModelAutomaticallyOption as NSObject: true
Once these lines are in place, CoreData will perform lightweight migrations correctly whenever they're required, including adding new entities, attributes, and relationships so you should be OK as long as you don't do anything that requires more action on your part - like changing the name of an entity or property.

IOS Coredata. Is it possible to see saved data without fetching it

I am working on core-data base project. I want to know that is it possible to see which data are saved in coredata without fetching it ?
For example:
I am using this Tutorial to learn coredata. **
Core Data demo from AppCoda
I have implement below method to save the data in Data-model.(coredata)
- (IBAction)save:(id)sender {
NSManagedObjectContext *context = [self managedObjectContext];
// Create a new managed object
NSManagedObject *newDevice = [NSEntityDescription insertNewObjectForEntityForName:#"Device" inManagedObjectContext:context];
[newDevice setValue:self.nameTextField.text forKey:#"name"];
[newDevice setValue:self.versionTextField.text forKey:#"version"];
[newDevice setValue:self.companyTextField.text forKey:#"company"];
NSError *error = nil;
// Save the object to persistent store
if (![context save:&error]) {
NSLog(#"Can't Save! %# %#", error, [error localizedDescription]);
}
[self dismissViewControllerAnimated:YES completion:nil];
}
but i want to know that, is it possible or is there any way to see what data are saved in my data model without Implement it's fetching method ?
Fetch From Coredata:
Yes. We can see saved data without fetching is .
After implement Save method core-data save sql file in Document Directory.
You can print it in nslog with using this Line.
NSLog(#"%#",[[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject]);
and you can see full path of document folder printed in log like this.
2015-10-13 12:40:51.253 MyStore[1860:69256] file:///Users/username/Library/Developer/CoreSimulator/Devices/C548BFA2-7B92-42E6-9D64-E16AFF0645D9/data/Containers/Data/Application/9C24913C-B295-4AA1-8DE9-A261CAA21624/Documents/
then you have to go in this folder. with selecting G0-> Go to folder... option.
Then print your Document path in go to folder window.
Note:- you have to write only this code in go to folder. (From ~/Library )
~/Library/Developer/CoreSimulator/Devices/C548BFA2-7B92-42E6-9D64-E16AFF0645D9/data/Containers/Data/Application/9C24913C-B295-4AA1-8DE9-A261CAA21624/Documents
and press GO button.
you will find your sqlfile.
open it with using some sqllite reader software.
SQL Lite pro this is the best software to read .sql file. open your file using it.
and you will see your saved data in it.
During runtime: No.
That is due the nature of Core Data. It is an object graph, not a data persistence solution. A fetch doesn't return an object if he can choose.
Outside of your app it depends on the persistence if any. If you decided to go for a sql store, then consider the sql answer. If you did select a different store type, then it depends on the type you went for.
For most projects are basic foundation objects fine since they can be serialized. If you parse an JSON you get foundation objects back. Consider Core Data when you deal with bigger data that need to be searchable even when you don't have the data in memory.

'NSObjectInaccessibleException' - CoreData sharing with TodayViewExtension

I've kinda implemented a today view extension with CoreData sharing in my app, I have multiple problems (like only one object showing when I have three) and a big one, "Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0xd0000000001c0004". Now, this only happens when I have the application open in the background, which leads me to believe that my app is leaving the store in a bad state, but that really shouldn't be happening. I'm using Persistent Stack, external 'library' to manage all of the CoreData (instead of AppDelegate) which is readable on https://gist.github.com/mluisbrown/7015953
CoreData Fetching from TodayView Extension:
-(void)viewDidLoad{
self.persistentStack = [[PersistentStack alloc] initWithStoreURL:self.storeURL modelURL:self.modelURL];
self.managedObjectContext = self.persistentStack.managedObjectContext;
}
- (NSURL*)storeURL
{
//NSURL* documentsDirectory = [[NSFileManager defaultManager] URLForDirectory:NSDocumentDirectory inDomain:NSUserDomainMask appropriateForURL:nil create:YES error:NULL];
// return [documentsDirectory URLByAppendingPathComponent:#"WhatIOwe.sqlite"];
NSURL *directory = [[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:#"group.com.bittank.io"];
NSURL *storeURL = [directory URLByAppendingPathComponent:#"WhatIOwe.sqlite"];
return storeURL;
}
- (NSURL*)modelURL
{
return [[NSBundle mainBundle] URLForResource:#"WhatIOwe" withExtension:#"momd"];
}
- (NSFetchedResultsController *)fetchedResultsController {
self.persistentStack = [[PersistentStack alloc] initWithStoreURL:self.storeURL modelURL:self.modelURL];
self.managedObjectContext = self.persistentStack.managedObjectContext;
if (_fetchedResultsController != nil) {
return _fetchedResultsController;
}
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription
entityForName:#"OweInfo" inManagedObjectContext:managedObjectContext];
[fetchRequest setEntity:entity];
NSSortDescriptor *sort = [[NSSortDescriptor alloc]
initWithKey:#"details.date" ascending:NO];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sort]];
[fetchRequest setFetchBatchSize:20];
NSFetchedResultsController *theFetchedResultsController =
[[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest
managedObjectContext:managedObjectContext sectionNameKeyPath:nil
cacheName:#"Root"];
self.fetchedResultsController = theFetchedResultsController;
_fetchedResultsController.delegate = self;
return _fetchedResultsController;
}
As suggested, I've tried a merge policy in my persistent stack:
[self.managedObjectContext.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:self.storeURL
options:#{ NSPersistentStoreUbiquitousContentNameKey : #"WhatIOwe",
NSMigratePersistentStoresAutomaticallyOption : #YES,
NSInferMappingModelAutomaticallyOption : #YES,
NSMergeByPropertyObjectTrumpMergePolicy : #YES}
error:&error];
Another observation, on configuring my NSManagedObjectContext, passing:
[psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:self.storeURL options:nil error:&error]; allows the extension to read the store (but still throw the error I'm having), but passing
[psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:self.storeURL options:#{ NSPersistentStoreUbiquitousContentNameKey : #"iCloudStore",
NSMigratePersistentStoresAutomaticallyOption : #YES,
NSInferMappingModelAutomaticallyOption : #YES,
} error:&error]; will result in the extension not reading any data whatsoever.
Side-note: psc is passed as
__weak NSPersistentStoreCoordinator *psc = self.managedObjectContext.persistentStoreCoordinator;
self.persistentStoreCoordinator = self.managedObjectContext.persistentStoreCoordinator;
What is happening here is that you have two different processes accessing the same Core Data store, each with it's own NSPersistentStoreCoordinator.
One process has modified the store - most likely a delete. The other process has no way of knowing that this delete occurred, and already had an object in memory that pointed to the now deleted data. When that process tries to access that object it must go to the store to get the data ("firing a fault"), which no longer exists.
Core Data is not designed for this kind of use, and the capabilities of extensions are very different than applications. If your extension is able to write to the same data that the application can you may reconsider your approach and make the extension only able to read the data, and never hold the data in memory for long. This will at least mitigate the most common ways to run into these problems.
Replying to above answer and the question:
"Core Data is not designed for this kind of use"
It totally is. The assessment is correct: Something has likely been deleted in the actual app, and the extension is not aware. Fortunately CoreData provides a way to deal with this case. Check out the stalenessInterval property of NSManagedObjectContext. It defines how long your in memory cache is good for. If you're having problems because your in memory cache goes out of date from disk store change because an external process is changing them, simply set the staleness interval to 0 in your extension, and that will tell CoreData to always fetch new values from the store and ignore the in memory cache.
If you're holding a reference to an object in memory, and that object is deleted in the store, you still may have issues, so always check to make sure the object you are accessing has not been deleted.
There are a few other options if you want to get more detail. You could send notifications from your main app to your extension when things get saved to provide a manual trigger for reloading your data. You could also send specific object ids across that have been deleted or modified and use the refreshObject... method to manually refresh. Or check out mergeChangesFromContextDidSaveNotification:. You might be able to manually serialize the dictionary that expects and then send it across.
You could also have the parent app handle all database accesses and send results back via notifications. This might be unnecessary.
All of this requires a bit of work, but you're going to run into that with any
database system where the database is being accessed across multiple processes, and there is caching.
There are multiple issues with your code which are likely leading to a confused Core Data state. I can't be certain that they're causing your problem, but at the moment things are messed up badly enough that trying to debug this specific error is getting ahead of things. These problems include:
Confusion about how you're sharing data between your app and the extension.
You can do this using iCloud, or you can do it by using an app group to share the persistent store directly. You appear to be attempting both, which is not just unnecessary but also likely to cause problems keeping the extension up to date.
If you use iCloud to share data, you do not need the app group, because both the app and the extension will get their data from iCloud. You don't share a local persistent store in this case, instead the data is transferred via iCloud.
If you use an app group to share the persistent store file, you have no need of iCloud. The app and the extension both access the same file, which is located in the group container. Each can both read and write it.
Conflicting iCloud setups. You're using different values for NSPersistentStoreUbiquitousContentNameKey in different places. Even assuming that iCloud is working properly, this is going to prevent you from sharing data. If the app and extension are going to share via iCloud, they need to access the same cloud store, but you seem to be directing them to use separate cloud data stores.
You're not actually using the merge policy you're aiming for. You're passing NSMergeByPropertyObjectTrumpMergePolicy as one of the options when adding the persistent store file, but this isn't actually a valid option there. I would have expected at least a console message about this, but if there isn't one then it means Core Data is just silently ignoring that key. You set a merge policy by setting the value of the mergePolicy attribute on your managed object context. With no merge policy, you're falling back on the default NSErrorMergePolicy.
Unusual, suspicious code when adding the persistent store. In most cases with Core Data you'd add the persistent store and then later on create one or more managed object contexts. You appear to be creating the context first and only later adding a persistent store. That's not necessarily wrong but it's very unusual. If I were working on this code, it'd be a red flag to look over the life cycle of the Core Data stack very carefully. Especially if, as your code comments indicate, you're not getting any data at all in some cases.
Again I'm not sure if the above is directly causing this specific error, but they're going to be causing problems of various types and it wouldn't be surprising if the resulting confused state leads to this error.

How to share Core Data with multiple Apps (not just an extension) using App Groups and avoid corrupted Core Data stores?

I made an iOS 8 app that uses the new app groups feature to share a Core Data store with an extension. It worked so well that I thought I would try it with 2 separate apps sharing a Core Data store in an App Group container. But while it worked between App and Extension, I am getting Core Data store corruptions issues when sharing with 2 apps.
Depending on the order in which I open the 2 apps, I get different errors:
Fetches cause this error:
CoreData: error: (522) I/O error for database at
/private/var/mobile/Containers/Shared/AppGroup/[…].sqlite. SQLite
error code:522, 'not an error’
Saves cause this error:
CoreData: error: (11) Fatal error. The database at
/private/var/mobile/Containers/Shared/AppGroup/[...].sqlite is
corrupted. SQLite error code:11, 'database disk image is malformed’
Or:
Core Data: error: -executeRequest: encountered exception = error
during SQL execution : PRIMARY KEY must be unique with userInfo = {
NSFilePath = "/private/var/mobile/Containers/Shared/AppGroup/[...].sqlite";
NSSQLiteErrorDomain = 19; } CoreData: error: (19) PRIMARY KEY must be unique
Here's how I did it by creating a framework to hold/manage the database
Add the same entry to your App Groups entitlements in each of your apps
Use it to create your databaseURL using:
[NSFileManager defaultManager] containerURLForSecurityApplicationGroupIdentifier:
database = [ [UIManagedDocument alloc] initWithFileURL: databaseURL]
[database saveToFileURL: database.fileURL forSaveOperation: UIDocumentSaveForCreating completionHandler: ^(BOOL success)
If successful, initialize the persistentContainer.
Now here's the tricky part... the managedObjectModel has to be defined by the framework. It cannot be in any of the apps. They can see it, but it has to be part of the framework's bundle.
That's the basic outline and there is a lot more to it, but with this you should be able to get there. Have fun!

+metadataForPersistentStoreOfType failure with NSSQLiteErrorDomain 14

I need to find the version of the model used in an existing persistent store so I can do a little post-processing after an automatic lightweight migration.
We've got a few devices in a state where we are unable to get the metadata for their persistent stores.
When we initialize the CoreData stack, we use NSPersistentStoreCoordinator's +metadataForPersistentStoreOfType:URL:error: method to get the metadata for the existing persistent store. Then we check if it's metadata is compatible with the metadata from the current object model to decide if we need to do a migration. We also pull the model versions from these two sets of metadata--so after the automatic lightweight migration we can do some simple post-processing based on the model versions.
The problem is that +metadataForPersistentStoreOfType:URL:error: is failing and returning nil on some devices. The error indicates NSSQLiteErrorDomain 14 and "I/O error for database at ". If I turn on SQLite debugging ("-com.apple.CoreData.SQLDebug 1") it doesn't produce much useful info:
CoreData: annotation: Connecting to sqlite database file at "/var/mobile/Applications/65838AB8-2DE4-4B1E-9837-FD252104448B/Library/slide_deck_database_1/StoreContent/persistentStore"
CoreData: sql: SELECT Z_VERSION, Z_UUID, Z_PLIST FROM Z_METADATA
CoreData: annotation: Disconnecting from sqlite database due to an error.
CoreData: error: (14) I/O error for database at /var/mobile/Applications/65838AB8-2DE4-4B1E-9837-FD252104448B/Library/slide_deck_database_1/StoreContent/persistentStore. SQLite error code:14, 'unable to open database file'
CoreData: annotation: Disconnecting from sqlite database.
metadataForPersistentStoreOfType failed with error: The operation couldn’t be completed. (Cocoa error 256.) (userInfo: {
NSSQLiteErrorDomain = 14;
NSUnderlyingException = "I/O error for database at /var/mobile/Applications/65838AB8-2DE4-4B1E-9837-FD252104448B/Library/slide_deck_database_1/StoreContent/persistentStore. SQLite error code:14, 'unable to open database file'";
})
I did find this article on Apple's website, which suggests a potential source of the issue: https://developer.apple.com/library/ios/qa/qa1809/_index.html But it doesn't seem to help with my problem. (It describes a way to migrate a persistent store and change the journaling options... but it assumes I already have an instance of NSPersistentStore, which I don't. I could add it via the PSC... but that would require migrating it, which defeats the whole purpose--again, because I'm trying to find the version of the existing store before I migrate it.)
One potential complication here is that I'm trying to switch from a UIManagedDocument store to a traditional CoreData stack (we're ditching UIManagedDocument because of a never-ending string of problems, and we understand a standard CoreData stack much better). In practice this hasn't seemed to have been a problem (until now?) but I thought it might be worth mentioning.
Edit: this is on an iPad (3rd generation) running iOS 7.1.1.
If you think the WAL vs. rollback thing is your problem, do the following:
Add the store to an NSPersistentStoreCoordinator using the rollback options as outlined in Technical Q&A 1809. If it can't do so for some other reason, you will get NO as the result of addPersistentStoreWithType:configuration:URL:options and a populated error.
To read the metadata, get the persistent store you just instantiated from the persistent store coordinator using persistentStoreForURL: .
At that point you can read the metadata for the store.
Example:
NSPersistentStore *store = nil;
NSError *error = nil;
NSDictionary *options = #{NSSQLitePragmasOption:#{#"journal_mode":#"DELETE"}};
if (! [persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:nil
URL:[self storeURL]
options:options
error:&error]) {
[self presentError:error];
}
store = [persistentStoreCoordinator persistentStoreForURL:[self storeURL]];
// read something out of the metadata.
id metaDataValue = [[store metadata] valueForKey: NSStoreUUIDKey];
You don't need to migrate it. You don't even need to keep that persistent store coordinator around. You can dispose of it as soon as you're done reading the metadata values.
Again, this somewhat assumes that your problem is the WAL vs. rollback SQLite store that is described in QA1809. Given the error that you are seeing any number of things could be the cause. For example, the store could have been previously corrupted by a borked write operation.

Resources