4 ms·
OP here... accessing the underlying SQLite database is very easy by using Core Data. Compare it with using the SQLite C API directly for one second: As things g
by LinaLauneBaer 13y ago
OP here... accessing the underlying SQLite database is very easy by using Core Data. Compare it with using the SQLite C API directly for one second: As things grow you will have more or less the same "problems" with the plain C API when it comes to concurrency. Have a look at FMDB (a popular SQLite wrapper written in Objective-C). You will see a class called FMDatabaseQueue which tries to simplify concurrency with SQLite. It follows the same "pattern" as concurrency typed contexts.
So I argue that you have the exact same problems when using Core Data that you have when using the raw C API for SQLite - conceptually. The benefit of using Core Data is a nicer API and other features that you would have to reimplement...
- plorkyeran 13y ago> So I argue that you have the exact same problems when using Core Data that you have when using the raw C API for SQLite - conceptually. That's pretty much the same conclusion I've come to from using CoreData, but I see that as a reason not to use CoreData. If I'm going to depend on a very complex closed-source library, I want it to solve hard problems, not just the easy problems. IMO CD isn't vastly harder than doing the same thing manually as some people will claim, but it's also not easier in nontrivial applications.