Core Data PersistentStore woes with SQLite
Core Data PersistentStore woes with SQLite
- Subject: Core Data PersistentStore woes with SQLite
- From: Elise van Looij <email@hidden>
- Date: Tue, 14 Nov 2006 15:20:11 +0100
I recently begin working with XCode's Core Data and its Data Model
and all was going pretty well until I ran into a nasty error when
testing my app, something along the lines of :
*** NSRunLoop ignoring exception 'no such column: I.ZISOPTIONAL' that
raised during posting of delayed perform with target 1611390 and
selector 'invokeWithTarget:'"
Now it so happened that isOptional was an attribute I had added to an
entity in my Core Data Model. As soon as I removed the attribute, lo
and behold, the error disappeared and my app was happy again. The
strange thing was, however, that not too long before that I had been
adding and removing attributes and entities to my heart's content
without any errors. A bit of googling showed me that the 'no such
column' error was associated with using a SQLite database as
NSPersistentStore, and indeed, I had recently changed my persistent
store from the defaul xml file to a SQLite database, following the
instructions in the CocoaDev tutorial "Build a Core Data
Application" [http://www.cocoadevcentral.com/articles/000085.php].
Poking around a bit further I found that though the isOptional
attribute certainly showed up in de data model, there was no
corresponding column in the SQLite database.
I was able to replicate the problem (using Xcode 2.4) in Apple's Core
Recipes sample application and in CocoaDev's BlogDemo app, so I filed
a bug report with Apple (problem id:4835662). I also found that
manually inserting columns and tables in the SQLite database (I use a
freeware app called SQLite Database Browser), seemed to solve the
problem: no more errors and adding and saving data works fine. I
cannot tell, however, whether it might not mess up some internal data
handling processes in Core Data. I did take care, by the way, to
follow the peculiar naming system in the database produced by Core
Data: all columnnames look something like ZISOPTIONAL and all tables
have integer columns named Z_ENT, Z_OPT and Z_PK (primary key).
Until this is fixed (it might be something really simple) I seems to
me that it would be best to stick to the NSXMLStoreType when still
doing a lot of experimenting in the datamodel. If you have already
switched to NSSQLiteStoreType and you haven't got too much valuable
data in your database, it might be easier to change the datamodel as
you wish and change the url to a different file, in the
appDelegate .m file:
url = [NSURL fileURLWithPath: [applicationSupportFolder
stringByAppendingPathComponent: @"MyProject2.myprojectDB"]];
This will create a new empty database with all the right tables,
relationships and indexes. You could try using SQLite Database
Browser import function to migrate your old data. Editing the
database itself, is probably best left as a last resort.
BTW, in one project I found a discrepancy between the appDelegates .h
and .m files:
- (IBAction)saveAction: sender; instead of - (IBAction)saveAction:(id)
sender;
Fixiing that rid me of NSRunloop exception but the 'no such column'
warning. I haven't been able to replicate this in other projects,
though, so it might be just a fluke.
Elise van Looij
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden