New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple NSEntityDescriptions claim the NSManagedObject subclass ... #275
Comments
How are you creating the model object? You should not use the merged model method, but load it with the file initializer.
Could also have to do with Swift modules.
Kind regards,
Drew
… On 26 Jul 2018, at 22:43, Jason Ji ***@***.***> wrote:
Hi Drew,
In Xcode 10 I'm getting this warning in the console when I save new objects to Core Data. (Context: I have an NSManagedObject subclass called CDEvent which I'm creating and saving in this case, and my Core Data stack lives in a shared framework called FeedingKit.)
2018-07-26 16:34:30.268969-0400 Feeding[2936:3350281] [error] warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'FeedingKit.CDEvent' so +entity is unable to disambiguate.
CoreData: warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'FeedingKit.CDEvent' so +entity is unable to disambiguate.
2018-07-26 16:34:30.269522-0400 Feeding[2936:3350281] [error] warning: 'CDEvent' (0x7ffcb082c570) from NSManagedObjectModel (0x7ffcae58a4c0) claims 'FeedingKit.CDEvent'.
CoreData: warning: 'CDEvent' (0x7ffcb082c570) from NSManagedObjectModel (0x7ffcae58a4c0) claims 'FeedingKit.CDEvent'.
2018-07-26 16:34:30.269984-0400 Feeding[2936:3350281] [error] warning: 'CDEvent' (0x7ffcb0c09380) from NSManagedObjectModel (0x7ffcb0c06530) claims 'FeedingKit.CDEvent'.
CoreData: warning: 'CDEvent' (0x7ffcb0c09380) from NSManagedObjectModel (0x7ffcb0c06530) claims 'FeedingKit.CDEvent'.
I investigated a little bit using the memory graph debugger and noticed that there are in fact three NSManagedObjectModels while my app is running. One of them comes from my own Core Data stack, and two of them come from Ensembles (CDEPersistentStoreEnsemble has a managedObjectModel, and CDEEventStore has a managedObjectContext that points to a persistentStoreEnsemble which points to a managedObjectModel).
So far, I haven't noticed this warning actually causing any problems - my app and Ensembles work as desired. The warning is disconcerting, though, and I'm not sure if you're already aware of it and/or have an easy solution to fix or suppress it. Any ideas?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@drewmccormack I'm creating the model object the same way Ensembles is, I believe - by using I'm curious about your comment about Swift modules. How do you think that could affect things? In my xcdatamodeld file, I have the module for my Core Data object defined as |
Actually, your comment about asking about the model object helped me to realize I need to be researching If I create an entity description myself and use it to call the designated initializer, the warning is no longer generated. I guess whatever entity description they try to use in that convenience method was getting confused by the multiple managed object models. Just leaving this explanation here in case anyone else stumbles into this warning and searches the Ensembles issues for something like it. Anyway, resolved - thank you for your comment, which was helpful! |
Ah, good catch. Glad you found it.
… On 29 Jul 2018, at 04:06, Jason Ji ***@***.***> wrote:
Actually, your comment about asking about the model object helped me to realize I need to be researching NSManagedObjectModel and NSEntityDescription, and I realized after reading up on the documentation about those two classes what the problem was. I was creating my managed objects using the convenience initializer init(context:) <https://developer.apple.com/documentation/coredata/nsmanagedobject/1640602-init?changes=_2>, which probably calls into the designated initializer init(entity:insertInto:) <https://developer.apple.com/documentation/coredata/nsmanagedobject/1506357-init?changes=_2>.
If I create an entity description myself and use it to call the designated initializer, the warning is no longer generated. I guess whatever entity description they try to use in that convenience method was getting confused by the multiple managed object models.
Anyway, resolved - thank you for your comment, which was helpful!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#275 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEuABSBG4k0awDaQBoQoWIWn1VhsBQtks5uLRiLgaJpZM4VihCJ>.
|
I had the same issue recently so I made a simple extension on import CoreData
public extension NSManagedObject {
convenience init(context: NSManagedObjectContext) {
let name = String(describing: type(of: self))
let entity = NSEntityDescription.entity(forEntityName: name, in: context)!
self.init(entity: entity, insertInto: context)
}
} Posting here in case anyone else comes across this. This way you don't need to update any of the call-sites. 👍
|
Just a comment to @shaps80 that it is probably best not to override the preferred initializer and instead provide a new convenience initializer, i.e. convenience init(using context: NSManagedObjectContext) that does the same as what you describe. |
@ksoftllc fair call 😬 |
@shaps80 Your suggestion has saved me twice! Great call. |
Hi Drew, I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not. And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes. So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked. I have found multiple entries in Stack Overflow that talk about this problem. So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue. What do you think? |
I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
Drew
… On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
Hi Drew,
I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
I have found multiple entries in Stack Overflow that talk about this problem.
So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
In my case the model is loaded on the main thread. Also Ensembles loads the model on the main thread. So this is not the issue.
But I understand your issue.
What about changing the API to provide both? We could still leave the old API for backwards compatibility and provide a Deprecated indication so that we do not break all the apps. And then introduce the new API which provides both model and modelURL.
What do you think?
… On 11 Apr 2021, at 14:58, Drew McCormack ***@***.***> wrote:
I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
Drew
> On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
>
>
> Hi Drew,
>
> I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
>
> And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
>
> So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
>
> I have found multiple entries in Stack Overflow that talk about this problem.
>
> So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
>
> What do you think?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BGCUC4DH57QHDVKH3TIGMHFANCNFSM4FMKCCEQ>.
|
I don’t think that will work. The URL is needed to load each version in the model, so Ensembles will still load the model again. It can’t use the model you pass to check for compatibility, because it is only the most recent model.
If you can find a way to do it, put in a PR and I am happy to look at it.
To me, this is a very poor API from Apple. They provide the means to load a model as much as you like, in different situations. There should be no assumption that an app only loads a model once. There is a similar problem with the mergedModel, which will just take any core data model it finds and put it all together, including the internal Ensembles model!
Drew
… On 11 Apr 2021, at 15:12, pascalfribi ***@***.***> wrote:
In my case the model is loaded on the main thread. Also Ensembles loads the model on the main thread. So this is not the issue.
But I understand your issue.
What about changing the API to provide both? We could still leave the old API for backwards compatibility and provide a Deprecated indication so that we do not break all the apps. And then introduce the new API which provides both model and modelURL.
What do you think?
> On 11 Apr 2021, at 14:58, Drew McCormack ***@***.***> wrote:
>
>
> I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
>
> There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
>
> Drew
>
> > On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
> >
> >
> > Hi Drew,
> >
> > I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
> >
> > And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
> >
> > So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
> >
> > I have found multiple entries in Stack Overflow that talk about this problem.
> >
> > So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
> >
> > What do you think?
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub, or unsubscribe.
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BGCUC4DH57QHDVKH3TIGMHFANCNFSM4FMKCCEQ>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ABPEN4AB3GUSXUQCRTTIGN43ANCNFSM4FMKCCEQ>.
|
I agree on the poor design from Apple’s side. Core Data has some strange issues that are really hard to debug.
The even stranger thing is, that the other loads in ensembles of the managed object model do not seem to bother at all. Do not ask me why!
I will make some more tests to see, if with this API change I can permanently solve the issue. If it works I will provide the Pull request.
Pascal
… On 11 Apr 2021, at 15:46, Drew McCormack ***@***.***> wrote:
I don’t think that will work. The URL is needed to load each version in the model, so Ensembles will still load the model again. It can’t use the model you pass to check for compatibility, because it is only the most recent model.
If you can find a way to do it, put in a PR and I am happy to look at it.
To me, this is a very poor API from Apple. They provide the means to load a model as much as you like, in different situations. There should be no assumption that an app only loads a model once. There is a similar problem with the mergedModel, which will just take any core data model it finds and put it all together, including the internal Ensembles model!
Drew
> On 11 Apr 2021, at 15:12, pascalfribi ***@***.***> wrote:
>
>
> In my case the model is loaded on the main thread. Also Ensembles loads the model on the main thread. So this is not the issue.
>
> But I understand your issue.
> What about changing the API to provide both? We could still leave the old API for backwards compatibility and provide a Deprecated indication so that we do not break all the apps. And then introduce the new API which provides both model and modelURL.
>
> What do you think?
>
>
>
>
> > On 11 Apr 2021, at 14:58, Drew McCormack ***@***.***> wrote:
> >
> >
> > I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
> >
> > There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
> >
> > Drew
> >
> > > On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
> > >
> > >
> > > Hi Drew,
> > >
> > > I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
> > >
> > > And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
> > >
> > > So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
> > >
> > > I have found multiple entries in Stack Overflow that talk about this problem.
> > >
> > > So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
> > >
> > > What do you think?
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub, or unsubscribe.
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BGCUC4DH57QHDVKH3TIGMHFANCNFSM4FMKCCEQ>.
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ABPEN4AB3GUSXUQCRTTIGN43ANCNFSM4FMKCCEQ>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BHZJN6IBY7CGFXIWTTIGR4LANCNFSM4FMKCCEQ>.
|
The issue isn’t really Core Data per se. It always worked before. The problem appeared when they added Swift support. In my view, they tried to be too cute, and their API is incomplete. I guess they were trying to make it super easy, and it is, but as soon as you want to do something a bit more advanced, it all breaks down.
Drew
… On 11 Apr 2021, at 16:09, pascalfribi ***@***.***> wrote:
I agree on the poor design from Apple’s side. Core Data has some strange issues that are really hard to debug.
The even stranger thing is, that the other loads in ensembles of the managed object model do not seem to bother at all. Do not ask me why!
I will make some more tests to see, if with this API change I can permanently solve the issue. If it works I will provide the Pull request.
Pascal
> On 11 Apr 2021, at 15:46, Drew McCormack ***@***.***> wrote:
>
>
> I don’t think that will work. The URL is needed to load each version in the model, so Ensembles will still load the model again. It can’t use the model you pass to check for compatibility, because it is only the most recent model.
>
> If you can find a way to do it, put in a PR and I am happy to look at it.
>
> To me, this is a very poor API from Apple. They provide the means to load a model as much as you like, in different situations. There should be no assumption that an app only loads a model once. There is a similar problem with the mergedModel, which will just take any core data model it finds and put it all together, including the internal Ensembles model!
>
> Drew
>
>
> > On 11 Apr 2021, at 15:12, pascalfribi ***@***.***> wrote:
> >
> >
> > In my case the model is loaded on the main thread. Also Ensembles loads the model on the main thread. So this is not the issue.
> >
> > But I understand your issue.
> > What about changing the API to provide both? We could still leave the old API for backwards compatibility and provide a Deprecated indication so that we do not break all the apps. And then introduce the new API which provides both model and modelURL.
> >
> > What do you think?
> >
> >
> >
> >
> > > On 11 Apr 2021, at 14:58, Drew McCormack ***@***.***> wrote:
> > >
> > >
> > > I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
> > >
> > > There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
> > >
> > > Drew
> > >
> > > > On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
> > > >
> > > >
> > > > Hi Drew,
> > > >
> > > > I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
> > > >
> > > > And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
> > > >
> > > > So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
> > > >
> > > > I have found multiple entries in Stack Overflow that talk about this problem.
> > > >
> > > > So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
> > > >
> > > > What do you think?
> > > >
> > > > —
> > > > You are receiving this because you were mentioned.
> > > > Reply to this email directly, view it on GitHub, or unsubscribe.
> > > —
> > > You are receiving this because you commented.
> > > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BGCUC4DH57QHDVKH3TIGMHFANCNFSM4FMKCCEQ>.
> > >
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ABPEN4AB3GUSXUQCRTTIGN43ANCNFSM4FMKCCEQ>.
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BHZJN6IBY7CGFXIWTTIGR4LANCNFSM4FMKCCEQ>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ACY6FJQJ5IL6OIGBLLTIGUR7ANCNFSM4FMKCCEQ>.
|
I agree and they just do not fix it. This is a longstanding problem.
I even tried to move to the new way to create the stores with NSPersistentContainer, but also this does not solve this issue.
Pascal
… On 11 Apr 2021, at 16:27, Drew McCormack ***@***.***> wrote:
The issue isn’t really Core Data per se. It always worked before. The problem appeared when they added Swift support. In my view, they tried to be too cute, and their API is incomplete. I guess they were trying to make it super easy, and it is, but as soon as you want to do something a bit more advanced, it all breaks down.
Drew
> On 11 Apr 2021, at 16:09, pascalfribi ***@***.***> wrote:
>
>
> I agree on the poor design from Apple’s side. Core Data has some strange issues that are really hard to debug.
>
> The even stranger thing is, that the other loads in ensembles of the managed object model do not seem to bother at all. Do not ask me why!
>
> I will make some more tests to see, if with this API change I can permanently solve the issue. If it works I will provide the Pull request.
>
>
> Pascal
>
> > On 11 Apr 2021, at 15:46, Drew McCormack ***@***.***> wrote:
> >
> >
> > I don’t think that will work. The URL is needed to load each version in the model, so Ensembles will still load the model again. It can’t use the model you pass to check for compatibility, because it is only the most recent model.
> >
> > If you can find a way to do it, put in a PR and I am happy to look at it.
> >
> > To me, this is a very poor API from Apple. They provide the means to load a model as much as you like, in different situations. There should be no assumption that an app only loads a model once. There is a similar problem with the mergedModel, which will just take any core data model it finds and put it all together, including the internal Ensembles model!
> >
> > Drew
> >
> >
> > > On 11 Apr 2021, at 15:12, pascalfribi ***@***.***> wrote:
> > >
> > >
> > > In my case the model is loaded on the main thread. Also Ensembles loads the model on the main thread. So this is not the issue.
> > >
> > > But I understand your issue.
> > > What about changing the API to provide both? We could still leave the old API for backwards compatibility and provide a Deprecated indication so that we do not break all the apps. And then introduce the new API which provides both model and modelURL.
> > >
> > > What do you think?
> > >
> > >
> > >
> > >
> > > > On 11 Apr 2021, at 14:58, Drew McCormack ***@***.***> wrote:
> > > >
> > > >
> > > > I don’t think that allows Ensembles to do a version check, which is the reason we get the URL. Ensembles needs to be able to access all the model versions, not just the most recent.
> > > >
> > > > There should be no user loading a model more than once, but maybe there is a thread issue. Perhaps we can ensure the model is loaded on the main thread.
> > > >
> > > > Drew
> > > >
> > > > > On 11 Apr 2021, at 14:35, pascalfribi ***@***.***> wrote:
> > > > >
> > > > >
> > > > > Hi Drew,
> > > > >
> > > > > I stumbled across this issue as well, and the problem really is, that the managedObjectModel should not be loaded more than one time. I have these strange crashes as well when using NSManagedObject.init(entity:insertIntoContext:). In some classes it works, in others it does not.
> > > > >
> > > > > And it does only crash, when I have ensembles enabled. When it is disabled then it never crashes.
> > > > >
> > > > > So I experimentally just changed the API to provide the NSManagedObjectModel instead of the URL to the model, so that Ensembles does not need to load it (again). After that my code just worked.
> > > > >
> > > > > I have found multiple entries in Stack Overflow that talk about this problem.
> > > > >
> > > > > So the real fix is, that the API of Ensembles should be changed to using the already loaded managed object model. This would permanently fix this issue.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > —
> > > > > You are receiving this because you were mentioned.
> > > > > Reply to this email directly, view it on GitHub, or unsubscribe.
> > > > —
> > > > You are receiving this because you commented.
> > > > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BGCUC4DH57QHDVKH3TIGMHFANCNFSM4FMKCCEQ>.
> > > >
> > >
> > > —
> > > You are receiving this because you were mentioned.
> > > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ABPEN4AB3GUSXUQCRTTIGN43ANCNFSM4FMKCCEQ>.
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5BHZJN6IBY7CGFXIWTTIGR4LANCNFSM4FMKCCEQ>.
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAS4ACY6FJQJ5IL6OIGBLLTIGUR7ANCNFSM4FMKCCEQ>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPAO5ADK2UHLO3G5HM6W6LTIGWWZANCNFSM4FMKCCEQ>.
|
hello im getting this same error,
} |
I'm not that familiar with NSPersistentContainer, but my guess is that it is just using the default models, merging them all into one. With Ensembles, it is necessary that you keep the models apart, because Ensembles has its own Core Data models. There should be a way with the persistent container to setup your own model, using the URL of your momd file, rather than letting the container look for all models. Take a look and google around for how you can setup the model for the container. (ChatGPT may even be able to write you code for this.) |
Here is code from ChatGPT. Don't know if it is correct, but probably is reasonable... Yes, I can certainly help you with that! Here's an example Swift code that sets up an NSPersistentContainer for Core Data using a specific model file: import CoreData
// Specify the name of your Core Data model file (without the file extension)
let modelName = "MyCoreDataModel"
// Get the URL of the specified model file in your app bundle
guard let modelURL = Bundle.main.url(forResource: modelName, withExtension: "momd") else {
fatalError("Failed to find model file with name: \(modelName).")
}
// Initialize an NSManagedObjectModel instance with the specified model file
guard let managedObjectModel = NSManagedObjectModel(contentsOf: modelURL) else {
fatalError("Failed to initialize managed object model with URL: \(modelURL).")
}
// Initialize an NSPersistentContainer with the specified managed object model
let persistentContainer = NSPersistentContainer(name: modelName, managedObjectModel: managedObjectModel)
// Load the persistent store for the container
persistentContainer.loadPersistentStores { storeDescription, error in
if let error = error as NSError? {
fatalError("Failed to load persistent store: \(error), \(error.userInfo)")
}
} In this example, you first specify the name of your Core Data model file (without the file extension) in a variable called Next, you initialize an Then, you initialize an Finally, you load the persistent store for the container using the |
Hi Drew,
In Xcode 10 I'm getting this warning in the console when I save new objects to Core Data. (Context: I have an NSManagedObject subclass called
CDEvent
which I'm creating and saving in this case, and my Core Data stack lives in a shared framework calledFeedingKit
.)I investigated a little bit using the memory graph debugger and noticed that there are three NSManagedObjectModels while my app is running. One of them comes from my own Core Data stack, and two of them come from Ensembles (
CDEPersistentStoreEnsemble
has amanagedObjectModel
, andCDEEventStore
has amanagedObjectContext
that points to apersistentStoreEnsemble
which points to amanagedObjectModel
). The two managed object models that the warnings reference correspond to the one from my own Core Data stack, and theCDEPersistentStoreEnsemble
's directly-ownedmanagedObjectModel
.So far, I haven't noticed this warning actually causing any problems - my app and Ensembles work as desired. The warning is disconcerting, though, and I'm not sure if you're already aware of it and/or have an easy solution to fix or suppress it. Any ideas?
The text was updated successfully, but these errors were encountered: