Having problems with Core Data?

When I add new entities, they dissappear after a while from the .xcdatamodeld file. Further, Xcode sometimes generate a third file when creating the NSManagedObject Subclass, containing some kind of macro that crashes the build. It looks like it is a template issue gone bad.

I have submitted rdar://2681978

Replies

Anything relevant in the release notes?



Core Data

  • For an attribute that allows specification of a custom class in its inspector, such as a transformable attribute, there is no way to specify the module or header from which to import that
    class. (25669424)

  • When using Core Data automatic code generation, changes made to a data model are not immediately visible to other code in the project.

    Workaround: Building the project again updates the generated code. (There is no need to clean the project before building it again.) (25789848)


  • Generated managed object classes are may not be created before the first build. (26564209). Workaround: Perform a clean build.

  • I'm having the same problems generating NSManagedObject subclass for my entities. I have attempted the opt-clean build -> build -> generate NSManagedObject subclass. I get the third __COREDATA_DATAMODELNAME__+CoreDataModel.swift file generated that throws two compiler errors. Further the subclass files themselves throw "Invalid redecleration of '<classname>'"

    I have more information. After looking at the build scripts I noticed there is a step that says "Generate code for data model <ProjectName>.xcdatamodeld." It turns out this utility is auto-generating all the NSManagedObjectModel subclasses for every Entity that is defined in your data model and dumping them into the DerivedData folder of your project.


    The later step "Compile Swift source files" is bringing in these NSManagedObjectModel subclasses found in the DerivedData folder for compilation.


    I looked in my target build settings and could find nothing that indicates that 1) Xcode 8 should auto-generate my entire Core Data model or 2) to compile files found in DerivedData.


    For verification I attempted to instantiate one of my Entities' NSManagedObjectModel subclass in a view controller file and the code complete was able to find the class. I can access all the data model properties as one might expect.


    I am not sure if this is new designed behavior in Xcode 8.


    I created a Core Data project in Xcode 7 and was unable to see this "Generate code for data model" compile step.

    This will teach me to read the beta release notes more carefully:


    "Xcode automatically generates classes or class extensions for the entities and properties in a Core

    Data data model. Automatic code generation is enabled and disabled on an entity by entity basis,

    and is enabled for all entities in new models using the Xcode 8 file format. This feature is available for

    any data model that has been upgraded to the Xcode 8 format. You specify whether Xcode generates

    Swift or Objective-C code for a data model using the data model’s file inspector.

    When automatic code generation is enabled for an entity, Xcode creates either a class or class

    extension for the entity as specified in the entity's inspector: the specified class name is used and the

    sources are placed in the project’s Derived Data. For both Swift and Objective-C, these classes are

    directly usable from the project’s code. For Objective-C, an additional header file is created for all

    generated entities in your model: The file name conforms to the naming convention

    'DataModelName+CoreDataModel.h'."


    Working as intended. Don't manually generate NSManagedObjectModel subclasses in new data models created in Xcode 8.

    nerdtypething, I would suggest watching this video to learn about the new auto subclass generation:

    https://developer.apple.com/videos/play/wwdc2016/242/


    When I do try and generate subclasses manually I also get the bug where it generates a file called __COREDATA_DATAMODELNAME__. I'm also experiencing a bug where choosing codegen Manual/None has no effect, the files are still generated in the derived folder and the model I excluded is added to the model umbrella header. This is only beta 1 after all.

    Thank you. I also am finding that choosing the codegen Manual/None is having no effect. It's quite crippling for unit testing since I can't expose any of my methods that take my managed object subclasses as parameters as public since the subclasses are all marked as internal and no way for me to make them otherwise.

    Okay, after watching the video linked to by malhal I found a work-around for Beta 1 that solves the ownership of the NSManagedObject subclass problem. By this I mean being able to manually generate the subclass and your project being in control of the primary class definition.


    In the core data model select the Entity you would like to control. Select the Data Model Inspector. Under the "Class" category there is a Codegen drop-down. Selecting "Manual/None" right now still auto-gens it (seems to be a bug). But if you select "Category/Extension" it will only create the properties/relationships definitions in an internal extension file stored in the DerivedData folder.


    Now manually generate the entity subclass. There is yet another bug here that generates those three files: the main class definition, the extension for properties and relationships and that weirdo file with the single macro defined. Simply delete all the files except the <Class>+CoreDataClass.swift file and everything should be okay.


    In my case now that I own the primary class definition I am free to make the class public and, thus, expose my local data manager class methods publicly to my unit tests.

    I have a similar but not identical problem.


    Whatever method I select in the Codegen pop-up for my data model entities, I get a set of swiftc errors of the following form for each entity:


    <unknown>:0: error: no such file or directory: '/Users.../DerivedSources/CoreDataGenerated/Library/.AppState+CoreDataClass.swift'
    <unknown>:0: error: no such file or directory: '/Users/.../DerivedSources/CoreDataGenerated/Library/.AppState+CoreDataProperties.swift'


    Note the dot prepended to each of the names of the generated files.vAnd indeed, if I go to the indicated directory, none of the generated files have this prepended dot.


    So it seems there's a mismatch between the names generated by whatever tool is creating these files, and whatever tool is trying to process these files.


    Additionally, if I try to generate the entity classes/extensions manually (in the prior, usual manner), Xcode crashes immediately after selected "File ->New...->File...->NSManagedObject subclass".


    Carl

    Thanks nerdtypething!


    This got me going on the right track. I did have to edit the xml file for the data model to finally make it so I could build my project without getting the auto generated object files. I added 'minimumToolsVersion="Xcode 7.0"' in <model> section of the file and things are now working as expected. I found that no matter what I tried, I could not get it to leave Code Gen to anything other than "Class Definition" when I opened the project again and it would continue to fail when trying to compile.


    This appears to be a bug with XCode.... did you file a bug report on your finding?


    Rich

    In Xcode 8 beta if Tools Version — Minimum in the File inspector of the .xcdatamodeld file is "Automatic (Xcode 8.0)", any changes you make to your data model will eventually disappear (for example, after opening a different file in the tab where you edited the data model and then immediately going back).


    The workaround is to select "Xcode 7.3" or older as the minimum version, make changes to your data model, build the project (optionally save and close the project, open it again and make sure everything is as it is supposed to be), and finally change the minimum version back to "Automatic (Xcode 8.0)", otherwise code generation for NSManagedObject subclasses won't work properly. Now you can create instances of the automatically generated NSManagedObject subclasses in your project.


    If changing the minimum version in Xcode doesn't help, you can try closing the project and directly editing the contents of .xcdatamodel file located inside .xcdatamodeld file whenever you need it (look for minimumToolsVersion property on the second line of the file). As always cleaning and building project should help if anything goes wrong.

    I'm still having this problem with beta 2. Has anyone else encountered this particular issue? Does anyone have any idea how I might be able to fix it?

    The core of the problem is that while Codegen is creating the right files, and putting them in the CoreDataGenerated folder, none of the generated files have a dot (".") prefixed to their name, which the compiler expects them to have.


    The expectation of this "." seems to arise from the datamodel's "Default" configuration, which for each entity (e.g. AppState) specifies a Class of the same name with the prepended dot (".AppState"). Even editing this configuration to remove the "." before each class name makes no difference: the same clases are generated, but the compiler still looks for a class with a prepended dot.


    I notice, too, that when I do edit the class names in the configuration to remove the dot, the class module for each enitity in the datamodel editor becomes (grayed-out) "Global namespace"; whereas if I select instead "Current Project Module", the dots all reappear in the configuration class names.


    So it seems this is all related to a module namespace issue/mismatch.


    Carl

    Hi Carl


    I have the exact same issue. I was wondering if you have solved it? If yes, how?


    Martin

    Exact same issue here, would love to know if there is a fix.

    The same issue stucks me with Xcode 8.1 public bersion.

    Yes, I got the same problems. Could the apple team help us as soon as possible, please?