CODEWITHSUNDEEP
ioscore-datasqlite
Goppinath
Goppinath

Reputation: 10739

Adopting Core Data with the existing App which is already using SQLite

I am developing an iOS App which exists since 2011 and SQLite is used as a primary database. After reading about Core Data and by considering it's advantages I have integrated Core Data into the App. Which means the old part of the App is running on top of SQLite and the new development is utilizing the Core Data with SQLite store, but totally separated .sqlite file from the existing one. But last few days some of the internal testes are reporting that the existing SQLite database is being corrupted. But the real reason is, the existing database became readonly. I dig into the internet and finally found an article about it from the sqlite.org https://www.sqlite.org/howtocorrupt.html under the section:

2.2.1. Multiple copies of SQLite linked into the same application

As pointed out in the previous paragraph, SQLite takes steps to work around the quirks of POSIX advisory locking. Part of that work-around involves keeping a global list (mutex protected) of open SQLite database files. But, if multiple copies of SQLite are linked into the same application, then there will be multiple instances of this global list. Database connections opened using one copy of the SQLite library will be unaware of database connections opened using the other copy, and will be unable to work around the POSIX advisory locking quirks. A close() operation on one connection might unknowingly clear the locks on a different database connection, leading to database corruption.

The scenario above sounds far-fetched. But the SQLite developers are aware of at least one commercial product that was released with exactly this bug. The vendor came to the SQLite developers seeking help in tracking down some infrequent database corruption issues they were seeing on Linux and Mac. The problem was eventually traced to the fact that the application was linking against two separate copies of SQLite. The solution was to change the application build procedures to link against just one copy of SQLite instead of two.

I would like to ask.

  1. Have anybody made an experience on this situation? Is it possible to run Core Data alongside with the existing SQLite database?
  2. Is my scenario falling into the above mentioned Multiple copies of SQLite problem? Any other advices?
  3. Why Core Data makes the existing sqlite as readonly time to time?

Upvotes: 0

Views: 38

Answers (1)

Tom Harrington
Tom Harrington

Reputation: 70976

Have anybody made an experience on this situation? Is it possible to run Core Data alongside with the existing SQLite database?

I haven't done this but it should be possible. There's nothing about one that prevents using the other in the same app.

Is my scenario falling into the above mentioned Multiple copies of SQLite problem? Any other advices?

Not unless you're embedding your own cope of the SQLite code in your app. That document refers to having more than one copy of SQLite, not to more than one data file.

Why Core Data makes the existing sqlite as readonly time to time?

It doesn't. If you're using SQLite directly, Core Data doesn't know or care about that file. They may both be using SQLite but that doesn't really mean anything here. Core Data doesn't doesn't get involved with non-Core Data code accessing non-Core Data files. Using SQLite calls directly is separate from anything you might do with Core Data.

It's possible that your app code is somehow mixing up data between the two, since you're half in one and half in the other. But neither approach inherently interferes with the other.

Upvotes: 1

Related Questions