Originally created by @iby on GitHub (Mar 20, 2020).
There are two methods for adding storage, this and this – both seem to be doing the exact same thing, but the latter returns a progress object.
However, when I'm calling it in my code, by default the compiler picks the second one and reports a warning about the unused invocation result (progress). When I tell the compiler to use the other one (via stack.addStorage(store, completion: { _ in }) as Void) I get NSPersistentStoreCoordinator exception:
CoreData: fault: Exception was caught during NSPersistentStoreCoordinator -performBlock: Cannot create an SQL store with a nil URL. with userInfo (null)
However, the method that returns the progress object works as expected. Can you elaborate if there's any difference between them or am I missing something?
Originally created by @iby on GitHub (Mar 20, 2020).
There are two methods for adding storage, [this](https://github.com/JohnEstropia/CoreStore/blob/d546ff154f989dcd1c6c22975e40ae8e1038bd00/Sources/DataStack%2BMigration.swift#L50) and [this](https://github.com/JohnEstropia/CoreStore/blob/d546ff154f989dcd1c6c22975e40ae8e1038bd00/Sources/DataStack%2BMigration.swift#L108) – both seem to be doing the exact same thing, but the latter returns a progress object.
However, when I'm calling it in my code, by default the compiler picks the second one and reports a warning about the unused invocation result (progress). When I tell the compiler to use the other one (via `stack.addStorage(store, completion: { _ in }) as Void`) I get `NSPersistentStoreCoordinator` exception:
```
CoreData: fault: Exception was caught during NSPersistentStoreCoordinator -performBlock: Cannot create an SQL store with a nil URL. with userInfo (null)
```
However, the method that returns the progress object works as expected. Can you elaborate if there's any difference between them or am I missing something?
adam
added the question label 2025-12-29 15:28:49 +01:00
I am assuming that you are using an SQLiteStorage, in which case the second one is the correct overload. The first one is meant for use for custom implementers of StorageType.
@JohnEstropia commented on GitHub (Mar 21, 2020):
I am assuming that you are using an `SQLiteStorage`, in which case the second one is the correct overload. The first one is meant for use for custom implementers of `StorageType`.
Good point, totally missed that. Not as critical, but perhaps it's worth to check inside the custom StorageType overload if the storage is LocalStorage and revert to the other method if so. If it gets invoked with erased LocalStorage storage type this would result in the same crash, wouldn't it?
@iby commented on GitHub (Mar 21, 2020):
Good point, totally missed that. Not as critical, but perhaps it's worth to check inside the custom `StorageType` overload if the storage is `LocalStorage` and revert to the other method if so. If it gets invoked with erased `LocalStorage` storage type this would result in the same crash, wouldn't it?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @iby on GitHub (Mar 20, 2020).
There are two methods for adding storage, this and this – both seem to be doing the exact same thing, but the latter returns a progress object.
However, when I'm calling it in my code, by default the compiler picks the second one and reports a warning about the unused invocation result (progress). When I tell the compiler to use the other one (via
stack.addStorage(store, completion: { _ in }) as Void) I getNSPersistentStoreCoordinatorexception:However, the method that returns the progress object works as expected. Can you elaborate if there's any difference between them or am I missing something?
@JohnEstropia commented on GitHub (Mar 21, 2020):
I am assuming that you are using an
SQLiteStorage, in which case the second one is the correct overload. The first one is meant for use for custom implementers ofStorageType.@iby commented on GitHub (Mar 21, 2020):
Good point, totally missed that. Not as critical, but perhaps it's worth to check inside the custom
StorageTypeoverload if the storage isLocalStorageand revert to the other method if so. If it gets invoked with erasedLocalStoragestorage type this would result in the same crash, wouldn't it?