GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
I have an entity that I do not want to generate a managed object subclass for so I leave Class blank.
I'd hoped that mogenerator would ignore this entity but, instead it generates files:
which I then have to delete. I suppose I could just create a class and ignore it but I'd really prefer either an option to exclude this entity or (preferably) for mogenerator to ignore entities with no class defined.
Instead of leaving Class field blank, try setting it to NSManagedObject (that's what Xcode's Data Modeler sets it to for new entities sans custom classes).
When I said "blank" perhaps I was misstating. What I mean is that it's blank, ergo it takes the default value of NSManagedObject (that's what I see in the field).
Hmm, that should work. mogenerator's Test Mule subproject has a an entity without a custom class just to test that (EntitySansCustomClass in https://github.com/rentzsch/mogenerator/tree/master/mogeneratorTestMule/mogeneratorTestMule_DataModel.xcdatamodel).
Do you have the same problem with Test Mule's datamodel?
Just had the same issue. When you delete the class from the Class field Xcode shows the grayish class name NSManagedObject.
However, the entity definition in the xcdatamodel contents actually looks like this:
<entity name="Client" representedClassName="" parentEntity="CoreDataObject" syncable="YES">
Notice that it doesn't have a representedClassName.
Putting NSManagedObject into the class field fixes this, the entity definition then looks like this, which does not produce _.h, _.m, .h and .m
<entity name="Client" representedClassName="NSManagedObject" parentEntity="CoreDataObject" syncable="YES">
Since representedClassName="" seems to be the new default (at least for Xcode 4.5), mogenerator should handle this correctly.
fix for #105 - If the class name of an entity is "" (i.e. empty strin…
…g) it should be considered to not have a custom subclass. Recent versions of Xcode use the empty string as default class for entities.