Open Radar

 
Summary:
When calling addPersistentStoreWithType:configuration:URL:options:error to add a custom NSAtomicStore subclass to a coordinator, the method fails and returns the following error.

2013-07-20 21:18:49.895 CSVApp[25869:c07] Error Domain=NSCocoaErrorDomain Code=134010 "The operation couldn’t be completed. (Cocoa error 134010.)" UserInfo=0x8481f90 {metadata={
    NSStoreUUID = "C1F1F935-60D0-4D33-AA20-90093D6AB6B5";
}, reason=The store type in the metadata does not match the specified store type.}

This is the metadata of the store at this point according to [self metadata] in the store instance:

$4 = 0x08427a60 {
    NSStoreUUID = "C1F1F935-60D0-4D33-AA20-90093D6AB6B5";
}

This was populated by a call to [super metadata]. metadataForPersistentStoreWithURL:error: is never being called on the atomic store class. 
In the case of an NSPersistentStore the metadata is populated by the framework with the NSStoreType key and the value of the store instance's type method. This does not seem to happen in the case of an NSAtomicStore subclass.


WORKAROUND:
Emulating NSIncrementalStore behavior does seem to work.
1. Implement loadMetadata: and add the NSStoreType entry to the metadata there. Note that the NSAtomicStore documentation does not indicate that loadMetadata: is required to be implemented. In the case of NSIncrementalStore the framework inserts the NSStoreType correctly into the metadata.
Example:
-(BOOL)loadMetadata:(NSError *__autoreleasing *)__unused error {
    NSMutableDictionary *mdata  = nil;
    // NSAtomicStore requires the metadata to be modified
    mdata = [[self metadata] mutableCopy];
    if (mdata != nil){
        [mdata setObject:[self type] forKey:NSStoreTypeKey];
    }
    [self setMetadata:mdata];
    [mdata release];
    
    return YES;
}

Once this is done addPersistentStoreWithType:configuration:URL:options:error will proceed and the framework will populate the rest of the metadata.

Steps to Reproduce:
See above. A simple application that demonstrates this can be provided if needed.

Expected Results:
addPersistentStoreWithType:configuration:URL:options:error should not fail for an NSAtomicStore that is returning a valid, consistent value for the type method. The framework should properly populate the metadata for this store just as it does for an NSIncrementalStore.

Actual Results:
Warp core breach.

Regression:

Notes:

Errrr shouldn't all persistent stores more or less be treated the same? It seems as though an NSAtomicStore subclass is treated differently that NSIncrementalStore or the built in stores.