Originally created by @deanWombourne on GitHub (Dec 23, 2016).
If corestore can't find the managed object subclass, an exception is thrown:
❗ [CoreStore: Assertion Failure] DataStack.swift:478 createPersistentStoreFromStorage(_:finalURL:finalStoreOptions:)
↪︎ The class 'Swift.String' for the entity <ClientEntity> does not exist. Check if the subclass type and module name are properly configured.
This should really be:
❗ [CoreStore: Assertion Failure] DataStack.swift:478 createPersistentStoreFromStorage(_:finalURL:finalStoreOptions:)
↪︎ The class 'TaskTimer.ClientEntity' for the entity <ClientEntity> does not exist. Check if the subclass type and module name are properly configured.
Swift.String is the class of the name of the missing class - the missing class is really TaskTimer.ClientEntity
Originally created by @deanWombourne on GitHub (Dec 23, 2016).
If corestore can't find the managed object subclass, an exception is thrown:
```
❗ [CoreStore: Assertion Failure] DataStack.swift:478 createPersistentStoreFromStorage(_:finalURL:finalStoreOptions:)
↪︎ The class 'Swift.String' for the entity <ClientEntity> does not exist. Check if the subclass type and module name are properly configured.
```
This should really be:
```
❗ [CoreStore: Assertion Failure] DataStack.swift:478 createPersistentStoreFromStorage(_:finalURL:finalStoreOptions:)
↪︎ The class 'TaskTimer.ClientEntity' for the entity <ClientEntity> does not exist. Check if the subclass type and module name are properly configured.
```
`Swift.String` is the class of the _name_ of the missing class - the missing class is really `TaskTimer.ClientEntity`
@deanWombourne commented on GitHub (Dec 29, 2016):
Yes, I've had odd things like this moving to swift 3 as well :/ I think it's using the generic version of cs_typeName instead of the String? one when you pass in a String, but I can't say why, or predict when it happens yet. I guess practice makes perfect :)
@deanWombourne commented on GitHub (Dec 29, 2016):
Yes, I've had odd things like this moving to swift 3 as well :/ I _think_ it's using the generic version of `cs_typeName` instead of the `String?` one when you pass in a `String`, but I can't say why, or predict when it happens yet. I guess practice makes perfect :)
@deanWombourne I think your PR should resolve this. I see you reopened the issue, have you found cases where the wrong overload still gets called?
@JohnEstropia commented on GitHub (Dec 31, 2016):
@deanWombourne I think your PR should resolve this. I see you reopened the issue, have you found cases where the wrong overload still gets called?
Nope - I pressed the wrong button submitting my last comment and closed it by mistake, so I reopened it. I wasn't sure when yo closed issues - fixed in master vs. released so I left it open for you to close when you want :) It's definitely fixed for me.
@deanWombourne commented on GitHub (Jan 2, 2017):
Nope - I pressed the wrong button submitting my last comment and closed it by mistake, so I reopened it. I wasn't sure when yo closed issues - fixed in master vs. released so I left it open for you to close when you want :) It's definitely fixed for me.
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 @deanWombourne on GitHub (Dec 23, 2016).
If corestore can't find the managed object subclass, an exception is thrown:
This should really be:
Swift.Stringis the class of the name of the missing class - the missing class is reallyTaskTimer.ClientEntity@JohnEstropia commented on GitHub (Dec 26, 2016):
Thanks. That is weird. Must be a Swift 3 side effect.
@deanWombourne commented on GitHub (Dec 29, 2016):
Yes, I've had odd things like this moving to swift 3 as well :/ I think it's using the generic version of
cs_typeNameinstead of theString?one when you pass in aString, but I can't say why, or predict when it happens yet. I guess practice makes perfect :)@JohnEstropia commented on GitHub (Dec 31, 2016):
@deanWombourne I think your PR should resolve this. I see you reopened the issue, have you found cases where the wrong overload still gets called?
@deanWombourne commented on GitHub (Jan 2, 2017):
Nope - I pressed the wrong button submitting my last comment and closed it by mistake, so I reopened it. I wasn't sure when yo closed issues - fixed in master vs. released so I left it open for you to close when you want :) It's definitely fixed for me.