Take the 2-minute tour ×

So I shipped an iPad app to the app store last march. It contains a Core Data model with a prepopulated store of binary tree data. I had written a tiny 64-bit OSX app to convert and extract data from an arbitrary 200MB weighing SQLite database to my custom Core Data model, resulting in a neat 20MB sized SQLite persistent store. All dandy, put into version control and never looked back.

Now my client has an updated database and they want to ship an updated app too. I figured this wouldn't take more than running the converter again and re-publishing to iTunesConnect, but no. My converter wouldn't run, or it wouldn't output the desired store. I spent hours and hours trying to figure out what was wrong, before finally reverting everything back to when I submitted my app to the store originally, and guess what, the converter wouldn't even convert that. Same code, same input database, same everything!

When looking at some data that my app resulted with, I found a weird discrepancy in how some values get stored in the Core Data model. In these three lines the group object is a Core Data entity. The identifier property is typed to Integer 16, as are all my integer based values in the model. Funny enough, when looking at the values after these three lines:

int identifier = 39899;
NSNumber *numIdentifier = [NSNumber numberWithInt:identifier];
group.identifier = numIdentifier;

I get these three values:

identifier:       39899
numIdentifier:    39899
group.identifier: -25637

Err, what? The number would of course stem from the source database, but even when inserting it manually, the last property on the core data entity gets garbled. Why on earth is that last line different? Negative what? Surely the value doesn't even come close to INT_MAX, why does it look like it's wrapping a signed int? And why is it different now when back in march, with the same code and same input database it used to work just fine? The only thing I can remember changing since then is an upgrade to OSX Lion. But surely that couldn't have affected this, right?

Would someone know what I'm doing wrong, what I've maybe been doing wrong last march already, and how I can fix this mess?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

A normal int is 32 bits, not 16. While 32 bits is plenty large enough for that value, 16 is not! -25637 is the overflowed value. You either need smaller numbers, or bigger variables.

share|improve this answer
Geez, you're right. 65536 unsigned. How on earth could this have worked in march then? I would check the answer mark right now to spare me more humiliation, but SO says to wait and indulge it some more... –  epologee Sep 20 '11 at 21:56
Maybe all the identifiers in the old database were less than 32K? –  Ernest Friedman-Hill Sep 20 '11 at 21:57
Yes, but weirdly enough I've reverted to the same input database as back then, because I couldn't figure this out. The converter runs for about 45 minutes, so I'll know in about an hour if changing all integers to 32 bit will have worked... –  epologee Sep 20 '11 at 21:59
add comment

See also "CoreData and Integer Width in iOS 5" http://www.seattle-ipa.org/2011/09/11/coredata-and-integer-width-in-ios-5/

"In iOS 3 or 4 you could get away with storing a wider integer than your model specifies but in iOS5 the width of integers is now being enforced."

Related Stack Overflow question Core Data change property from Integer 16 to Integer 32

share|improve this answer
That solves the mystery of why it worked in march, thanks for sharing! –  epologee Nov 2 '11 at 9:25
add comment

Your Answer


