NSLog a message when NSManagedObject Class's name is not as same as the entity's name in the CoreData Model.

[remaerd]

I have a subclass of NSManageObject which have a prefix in the Class name, and an entity without the prefix in the CoreData Model. So when I try to run it, it crash, and I had no idea why is not working. The README do not have any clues about entity name, And I just simply forgot them.

This is a tiny NSLog when an NSEntityDescription object is nil. So we can figure out what's had happen when we meet the same problem as I do.

[florianbuerger]

Had the same problem today, #65 does fix it for two and three letter prefixes (but it is an extremely naive solution)

[conradwt]

@remaerd The easiest recommendation here is to rename your entity in the model to match NSManagedObject class name. Personally, I tend to generate my classes from the entity model. Thus, these two things never get out of sync.

[supermarin]

There's an +entityName method you can override in your class

[remaerd]

It's not about there's an interface to solve the problem already. It's about how to make less mistake. Yes the '+entityName' solve the problem. But I had spend 3 days to realise the problems can be fixed by using the '+entityName'. There's no documents that tell us we need to rename it if the classname includes a prefix. So there will be more user like me, making the same mistake.

[supermarin]

@remaerd I agree with that, and am wondering if we should just NSLog or throw an exception. thoughts?

[remaerd]

@mneorr I was trying to push a commit which use the NSLog 7 months ago... And I'm not the best guy to write good code. Choose what you think is best.

[supermarin]

@remaerd thanks for your PR, and sorry it took so much. I've just swamped myself with tasks and different projects, and missed this one.

[remaerd]

I can do so little, THANK YOU for the ObjectiveRecord and your other contributions.

---

Greetings from Sean Cheng / Extremely Limited.

extremelylimited.com (http://extremelylimited.com/) zhengxingzhi.com (http://zhengxingzhi.com/)

On Thursday, January 9, 2014 at 5:16, Marin Usalj wrote:

@remaerd (https://github.com/remaerd) thanks for your PR, and sorry it took so much. I've just swamped myself with tasks and different projects, and missed this one.

—
Reply to this email directly or view it on GitHub (#13 (comment)).

[conradwt]

@mneorr I would simply do what Core Data does and allow the exception to happen. Thus, I don't think you have to do anything (i.e. NSLog or explicitly throw exception) here because it's handled by Core Data.

[florianbuerger]

I think we should break as soon as possible when something is wrong. Core Data does throw an exception but a few calls into the Core Data stack an you have to think about what is going wrong.
If a method cannot do what it should if a variable is nil we should stop right there and give the user the required information, e.g. NSParameterAssert(entity)

[supermarin]

@stephencelis should we introduce something like ORDLog() macro that'd check #ifdef ORD_DEBUG and then invoke NSLog?
That way we could skip those ifs laying around