Re: CoreData / SQL hang on save
Re: CoreData / SQL hang on save
- Subject: Re: CoreData / SQL hang on save
- From: Greg Hoover <email@hidden>
- Date: Sat, 19 Sep 2009 10:18:52 -0700
Hi Anthony,
I actually debugged this issue with an Apple engineer and it turns out
there's a bug connected to float and double types when you write back
identical or nearly identical values. I solved it by extending
NSManagedObjectContext and calling this bit of code instead of the
regular save:
- (BOOL)safeSave {
BOOL success = YES;
if ([self hasChanges]) {
for (id object in [self updatedObjects]) {
if (![[object changedValues] count]) {
[self refreshObject: object
mergeChanges: NO];
}
}
NSError *error = nil;
if (![self save: &error]) {
MSReportErrorMessage(error);
success = NO;
}
}
return success;
}
This was on 10.6 btw, and may have been fixed in the latest release (I
haven't checked).
Greg
On Sep 19, 2009, at 3:00 AM, Anthony Mittaz wrote:
Hi Greg,
Just had this exact same problem for the last week or so, aka
"binding not implemented for SQLType 7" on a core data iPhone 3.0
project.
Basically what went wrong is that I was trying to save an int64 into
a double column...
Not sure if you ever fixed your problem but this may help.
(used -com.apple.CoreData.SQLDebug 3 in order to see what was
happening under the hood)
Regards
Anthony Mittaz
Thanks for you response.
The problem actually just started showing up in 10.6 (wasn't a
problem in 10.4 or 10.5). :-/
The hang stopped for a few launches and reverted to its previous
output: "binding not implemented for SQLType 7". But then it
happened again... The SQL file does not have null values for any
Z_OPT fields.
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE
Z_PK = ? AND Z_OPT = ?
CoreData: sql: UPDATE ZSTOCK SET ZOPEN = ?, Z_OPT = ? WHERE Z_PK = ?
AND Z_OPT = ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE
Z_PK = ? AND Z_OPT = ?
CoreData: sql: ROLLBACK
binding not implemented for this SQLType 7
safe save
CoreData: sql: BEGIN EXCLUSIVE
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE
Z_PK = ? AND Z_OPT = ?
CoreData: sql: UPDATE ZSTOCK SET ZOPEN = ?, Z_OPT = ? WHERE Z_PK = ?
AND Z_OPT = ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET Z_OPT = ? WHERE Z_PK = ? AND Z_OPT
= ?
CoreData: sql: UPDATE ZSTOCK SET ZEPS = ?, ZASK = ?, Z_OPT = ? WHERE
Z_PK = ? AND Z_OPT = ?
CoreData: sql: ROLLBACK
binding not implemented for this SQLType 7
CoreData: annotation: total fetch execution time: 0.0000s for 0 rows.
CoreData: annotation: total fetch execution time: 0.0000s for 0 rows.
safe save
Thanks,
Greg
On Aug 25, 2009, at 1:16 PM, Melissa J. Turner wrote:
On Aug 25, 2009, at 02:19, Greg Hoover wrote:
I've run into a hang in CoreData save. I'm the single coordinator,
multiple object contexts threading model and a SQL store (though it
seems to happen with XML as well). The hang occurs inside the
NSSQLCore and seems to just loop endlessly. The SQL output supports
this. Requests performed at launch succeed as expected, but the app
quickly reaches a point where Optimistic locking failure exceptions
are thrown with an endless sequence of ROLLBACKs followed by
UPDATEs. All of the contexts are using the
MergeByPropertyObjectTrump merge policy.
Any insight would be much appreciated.
There is a known issue on 10.5.* that results in Core Data entering
an infinite loop during save if the database has been corrupted such
that the optimistic locking column is set to NULL.
A way to tell would be to run sqlite3 on the database and execute
the following SQL statement:
select Z_PK, Z_OPT from ZSTOCK where Z_PK IN (1, 4);
I'm guessing you'll get back something that looks like:
1|
4|
Which means that something has stuffed unexpected NULLs into your
database.
The issue has been fixed in 10.6, but the only real workaround on
10.5.* is to manually repair the database by setting the value of
the Z_OPT column to be non-null (1 is always a good option).
Cheers,
+Melissa
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden