4 ms·
There is another option on iOS: use CoreData and don't sweat what's underneath it.
by rimantas 12y ago
There is another option on iOS: use CoreData and don't sweat what's underneath it.
- sehugg 12y agoCore Data uses SQLite as its backend by default, so you may still potentially run into these kind of problems -- if say, an ad network decided to statically link in its own SQLite version. I have been frustrated by persistent corruption in a production app that solely uses CD, though I don't know if it's related to multiple SQLite instances. EDIT: An ad library is probably a bad example since it wouldn't create files that are normally touched by the user app. Unless you were making an app to visualize ad library requests...
- deleted 12y ago[deleted]
- scott_karana 12y agoYes, I think sehugg understood that, and the point was that even if you are diligent about solely using CoreData, someone else, like your ad provider, might introduce another version of SQLite in their library, so you'd be screwed anyways.
- pdpi 12y agoI fail at reading comprehension.
- simscitizen 12y agoNo you wouldn't. You'd only be screwed if you used that other copy of SQLite to open the SQLite file used by CoreData to store data. Which you shouldn't be doing anyway.
- teraflop 12y agoThe article gives quite a few reasons why you might not want to do that. For instance, if you want to encrypt your data at rest, or you want the new features and performance improvements from the last 2 years of SQLite development.
- rimantas 12y agoIf you use Core Data you are not accessing raw SQLite, so the last two years don't mean much. And there are more often good reasons to use Core Data than not.