CoreData - can't set empty string as default value for attribute

This is a very interesting question. After some testing I don't think this is possible because of the way the text field in the data model is configured.

In principle, you could use the unicode empty-set character of \u2205 to represent a default empty string but the text field does not seem to accept any escapes so it converts any attempt to escape a unicode character code to the literal string of the code characters themselves e.g. entering '\u2205' ends up as the literal text '\u2205'.

In theory you could write a utility app to read in the graphically generated managed object model file and then programmatically set the attribute default to equal an empty string and then save the file back to disk. I say "in theory" because there is no documented way to way to save a managed object model file from code. You can read one and modify it in memory but not persist the changes.

Bit of an oversight, I think.

I don't think you have any choice but to set the default empty string pragmatically when the model first loads. That is simple to do but it's ugly and you'll have to remember you did (especially if you migrate versions) but I think right now that is the only choice.

Whip out your favorite XML editor (I just used Emacs) and dive down to the contents file inside the .xcdatamodel bundle inside the .xcdatamodeld bundle. Then just add a defaultValueString="" XML attribute to the <attribute>...</attribute> element inside the <entity>...</entity> brackets.Here's an example:

<attribute name="email" attributeType="String" defaultValueString="" syncable="YES"/>

I can't speak to whether this survives migration since I haven't had to do that yet.

I resolved this by overriding the getter for my field - if it contains null, I return an empty string instead:

-(NSString *)unit {    if ([self primitiveValueForKey:@"unit"] == NULL) {        return @"";    } else {        return [self primitiveValueForKey:@"unit"];    }}

So far it seems to be doing the trick, and I would imagine it wouldn't impact migrations (although I don't know enough about them to say for sure). I don't really care whether there's a null or an empty string in the db, after all - so long as I get "" instead of null when I ask for the field.