Thanks, spawning another process is a good idea. Filing a bug with Apple is probably not going to work, they don't encourage accessing a CoreData managed database without going through CoreData.
2014-06-05 13:49 GMT+02:00 David Empson <demp...@emptech.co.nz>: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
