Nick, I was in fact using existing databases - actually the update I'm working on has a migration involved in it too. I didn't mention it originally as I'd ruled it out as the cause, but that actually helped fix the problem. Since I was already migrating the data (with custom entity migration policies) it was trivial to rename the relationships at the same time. And that worked - the migration can read the existing database and it fixed my issue when attempting to read the new one.
I'm not sure if that would help, and if it did, whether it would be a better solution, but I wanted to point it out as throwing out existing data was not an option for me either. Maybe it's worth trying a migration and seeing if you can get things upgraded correctly that way? A little heavy handed for what does indeed seem to be a nasty regression, but better than losing data. I realise it's not exactly the same problem as I was seeing, but they do seem to have a lot in common. HTH, -nick On 06/08/2011, at 3:55 AM, Keary Suska wrote: > On Aug 4, 2011, at 2:30 PM, Nick Zitzmann wrote: > >> I tried searching around and found one other person who had the same >> problem[1], but no one followed up with a good solution for existing >> databases. >> >> I have an entity with a many-to-many relationship to itself, called >> "parents" and "children". And when I take a database that was made by an >> application built by Xcode 3.2.6 and move that application to Xcode 4.1, I'm >> now getting this error when trying to look up something in that entity: >> >> I/O error for database at /path/to/mydatabase.db. SQLite error code:1, 'no >> such table: Z_16PARENTS' >> >> It looks like the model compiler made a subtle change to the many-to-many >> table that is part of the model used to make the database during the switch. >> How do I make it so that it uses the same tables that it used to use? >> Throwing out and rebuilding the existing database is not an option. >> >> I already tried changing the Mac OS X deployment target, since I noticed >> that the deployment target is passed to momc, but that did not make any >> difference. >> >> I was able to work around the problem by creating a custom build rule that >> builds the data model using Xcode 3's momc tool instead of Xcode 4's tool, >> and while that did solve the problem, there has got to be a better way. But >> what is that way? I can't believe Xcode 4 would ship with such a regression >> in momc... >> > > Depending on the number of differences you could simply fire up the sqlite > client and rename the tables in the database to what the new model compiler > generates. > > HTH, > > Keary Suska > Esoteritech, Inc. > "Demystifying technology for your home or business" > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/macdive%40thedoorisajar.org > > This email sent to macd...@thedoorisajar.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
