On 5/06/2014, at 11:21 pm, Lasse Jansen <la...@lasselog.com> wrote: > Hi, > > we have a Mac app that uses CoreData which internally uses SQLite. Some of > the queries are not expressible within CoreData, so we send them manually > using the sqlite library that comes with Mac OS X. Now some of our users > have reported that their database file got corrupted and after some > researching I think it's because of multiple copies of SQLite being linked > into the same application as described here: > > http://www.sqlite.org/howtocorrupt.html > > Even though we link CoreData to our application and CoreData uses sqlite > internally we still have to explicitly link libsqlite as the CoreData > version of sqlite is inaccessible due to the usage of two-level-namespacing. > > So I have two questions: > 1. Can this be solved without dropping CoreData? > 2. If not, is there a workaround that we could use until we replaced > CoreData with something of our own?
One possibility would be to structure your application so that it spawns a subprocess (not just another thread), then one process uses CoreDate while the other uses SQLite directly. Separate processes should avoid the issue with other locks in the same process being broken by a close. Of course that will add more complexity due to needing to do some kind of inter-process communication, but it might be a manageable solution while you factor out CoreData. Another idea which might be worth pursuing, but probably not in a reasonable timeframe: file a bug report with Apple, requesting that they add a means for applications to directly invoke the SQLite instance inside CoreData (with sufficient evidence of the problem you are encountering to explain why this design flaw in CoreData prevents safe independent use of SQLite), or extend CoreData as required so that you don't need to work around it. > I'm thinking of this: > As the problem seems to occur due to calling close() and we only use > libsqlite for read-only access, would just not closing the read-only > database connection prevent the corruption? Probably not, because when CoreData closes its connection, your read-only connection via the second instance of SQLite will have broken locks from then on. If CoreData opens the database again, you could get access collisions and read incomplete data, due to your reader not being blocked while a CoreData write is in progress. -- David Empson demp...@emptech.co.nz Snail mail: P.O. Box 27-103, Wellington 6141, New Zealand _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
