Best practice for multi-users with encrypted realm FRC cache

[jasper-chan]

I'm currently using your FRC in a platform that supports multiple users. Encryption is also turned on for realm. I noticed that if I logged out, and tried to log in as a different user, an exception stating the wrong encryption key is being used to open the cache. I tried calling deleteCacheWithName and passing in nil to delete everything, but then another exception:

Terminating app due to uncaught exception 'RLMException', reason: 'Realm at path '/Users/jasperchan/Library/Developer/CoreSimulator/Devices/60242241-EB72-4C8C-A7DA-8D017E03F860/data/Containers/Data/Application/540996A9-147F-4AAC-B9CA-EB03A50B4AE5/Documents/RBQFetchedResultsControllerCache/sceneFileCache/sceneFileCache.realm' already opened with different encryption key'

I was hoping if you could provide the best practice using this FRC to resolve this issue. Thanks

[bigfish24]

How have you setup the cache to use encryption, by default it doesn't?

[jasper-chan]

I've done my best to mimic your example. I didn't set encryption anywhere for FRC.

- (RBQFetchedResultsController *)createSceneFileFRC
{
    @try
    {
        RLMRealm *defaultRealm = [RLMRealm defaultRealm];
        NSPredicate *predicate = [NSPredicate predicateWithFormat:@"status = %d", SceneFileStatus_OPEN];

        RBQFetchRequest *fetchRequest = [RBQFetchRequest fetchRequestWithEntityName:@"RLMSceneFile"
                                                                            inRealm:defaultRealm
                                                                          predicate:predicate];

        // Edit the sort key as appropriate.
        RLMSortDescriptor *sortDescriptor = [RLMSortDescriptor sortDescriptorWithProperty:@"lastModifiedDate" ascending:NO];
        NSArray *sortDescriptors = @[sortDescriptor];
        [fetchRequest setSortDescriptors:sortDescriptors];

        RBQFetchedResultsController *FRC = [[RBQFetchedResultsController alloc] initWithFetchRequest:fetchRequest
                                                                                  sectionNameKeyPath:nil
                                                                                           cacheName:@"sceneFileCache"];

        return FRC;
    }
    @catch (NSException *exception) {
        [ErrorDebugHelper logException:THIS_FILE thisMethod:THIS_METHOD exception:exception];
        return nil;
    }
}

Then I just call performFetch.

[bigfish24]

Ah I think the issue is that you have set the default configuration to use encryption and FRC uses the default configuration to create a second Realm file. I can create a PR to fix.

However, the exception you are seeing is that you haven't actually deallocated the FRC, so there is a RLMRealm for the cache hanging around. You will need to release the FRC (i.e. don't hold a strong reference to it so ARC can clean up), and then call the deleteCacheWithName: passing in nil. This will actually remove the underlying Realm file.

[bigfish24]

So this PR would fix your issue: https://github.com/Roobiq/RBQFetchedResultsController/pull/70

But I am not sure this is really what you want. I think you would want the FRC to be encrypted as well, since this would defeat the encryption.

I guess my suggestion is that you should not use a cache, so the cache ends up being in-memory. Just pass nil for the cache name.

If not then you will need to follow my instructions to make sure the FRC is deallocated, and thus the FRC cache Realm will be closed, allowing you to delete it safely and recreate with a new encryption key.

[jasper-chan]

I would agree with you that it would defeat the purpose of encryption, but thanks for doing the PR!

I'll try without using cache and see what the performance is like. Have you done any performance testing between in-memory and cache?

Thanks!

[jasper-chan]

@bigfish24 So I did a little test on our software and I noticed with a couple thousand records, eventually the app is killed off due to memory usage if I was to use in-memory.

Your suggestion to ensure the FRC is being properly deallocated is correct. Thanks for your help!

[bigfish24]

I find it odd the memory use was that high with in-memory, as this points to a potential issue, but if you were able to properly deallocate the FRC and everything is working fine then I guess its not worth digging into.