4 ms·
Looks like someone missed the point of making a whole API on top of the database - to make accessing the database easier, not infinitely harder with more gotcha
by RyanZAG 13y ago
Looks like someone missed the point of making a whole API on top of the database - to make accessing the database easier, not infinitely harder with more gotchas than Apple's TOS. This reads less like a defense of Core Data and more like a guide book on why using Core Data is terrible idea.
- LinaLauneBaer 13y agoOP 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.