6 ms·
The Laws of Core Data
- adamnemecek 6y agoCoreData is a pain in the ass. It feels like it tries to be everything to everyone so it’s nothing to no one.
- chrismsimpson 6y agoEvery bit this.
- jonwinstanley 6y agoAre there any other decent alternatives for an iOS app?
- groue 6y agoYou can try https://github.com/groue/GRDB.swift https://github.com/groue/GRDB.swift It's a thin wrapper around SQLite, with convenience APIs for record types, robust support for concurrency, and a focus on GUI apps.
- m_st 6y agoHave a look at FMDB: https://github.com/ccgus/fmdb/ https://github.com/ccgus/fmdb/ I don't know or use it personally. But the developer behind it is very experienced and sells the nice, tried and true image editor Acorn here. https://flyingmeat.com https://flyingmeat.com
- neverartful 6y agoI used FMDB in a number of iOS apps (although it's been quite a few years back) and it was a pleasure to use. It was simple, well-designed, and with no surprises.
- liuliu 6y agohttps://dflat.io/ https://dflat.io/ Very different trade-offs. Focusing on separating mutations out and provide change subscription mechanism to facilitate one-way data flow UI design.
- jinjin2 6y agoWe had much more success with Realm: https://docs.mongodb.com/realm/ios https://docs.mongodb.com/realm/ios In terms of usability it was lightyears ahead of Core Data, and it actually worked smoothly with multi-threaded apps without breaking down constantly (as had been our experience with Core Data). It was a joy to work with.
- deleted 6y ago[deleted]
- maest 6y agoWhat is core data?
- kennywinker 6y agoApple’s ORM framework for iOS and Mac
- ElFitz 6y agoThat’s the thing. It isn’t an ORM, even though it’s often used like one
- jaygray0919 6y agoGood arguments about why to use a graph database for graphs and relational database for records.
- jonwinstanley 6y agoUnbelievable timing by Hacker News. I’m building a Swift app with Core Data for the first time and last night I was reading up on how the container/context/objects fit together :-)
- jb1991 6y agoUnbelievable!
- panic 6y agoApple's Frameworks teams tend to ship two kinds of APIs -- APIs designed around the needs of first-party apps and APIs designed specifically for third-parties to use. Core Data is characteristic of the second kind of API. It sounds cool in theory, but when you try to use it, it never really seems to do what you want it to. Hence the need to "use an abstraction layer" over an API which is itself an abstraction layer (sqlite) over an abstraction layer (file I/O).
- ElFitz 6y agoIt’s not just an abstraction layer over SQLite, or any database, for that matter, even though it is even often used and thus thought of as an ORM. It does have a persistence layer, but it is not it’s persistence layer. See https://nshipster.com/core-data-libraries-and-utilities/ https://nshipster.com/core-data-libraries-and-utilities/ > Contrary to popular belief, Core Data is not an Object-Relational Mapper, but rather an object graph and persistence framework [...] Using Core Data as an ORM necessarily limits the capabilities of Core Data and muddies its conceptual purity. But for many developers longing for the familiarity of an ORM, this trade-off is a deal at twice the price! Edit: should have read the post before replying to comments ^^’
- sradman 6y agoCore Data traces its roots over 25 years with NeXT's Enterprise Objects Framework (EOF) [1]: > Many of the core concepts of EOF re-emerged as part of Core Data, which further abstracts the underlying data formats to allow it to be based on non-SQL stores. Apple also released CloudKit which synchronizes with FoundationDB’s Record Layer making Core Data an alternative to Google Firebase and Amazon’s GraphQL based AppSync. It is an object oriented approach to data access which many developers prefer while others dislike. SQLDelight [2] is a YeSQL-like alternative for the anti-ORM and anti-Vendor-Lock-In folks but it relies on Multiplatform Kotlin to support both Apple and Android ecosystems. Engineering is about managing trade-offs given a set of constraints. Core Data is sometimes a fine choice. [1] https://en.wikipedia.org/wiki/Enterprise_Objects_Framework https://en.wikipedia.org/wiki/Enterprise_Objects_Framework [2] https://github.com/cashapp/sqldelight https://github.com/cashapp/sqldelight
- kenver 6y agoI’ve been working with iOS since about 2008. I haven’t touched core data for about 10 years...it’s not worth the pain.
- andrekandre 6y agobiggest problem with core data (imo) was they never ported the data controllers (nsobjectcontroller, nsarraycontroller, nstreecontroller etc) which makes dealing with core data much easier (to say nothing about the lack of bindings as used in appkit)
- blacktriangle 6y agoTake a look at NSFetchedResultsController, it gives you what you want from NSObjectController and NSArrayController, and there aren't really UI widgets on iOS where NSTreeController is appropriate like there are in AppKit.
- ericlewis 6y agoThere are now, DisclosureGroups & OutlineGroup especially would be places in SwiftUI where a NSTreeController might be useful.
- andrekandre 6y agothere might not be any native uis in uikit that need nstreecontroller, but ive done custom uis in appkit that utilized nstreecontroller (think of a diagramming ui with groups and child groups) and would love to have been able to use those in uikit too, with pure data bindings....
- m_st 6y agoPersonal take after quite a few years of experience: ORMs are great for quick and easy prototyping. But in no way I would ever use another ORM in any application again. Simple helpers like Dapper (C#/.NET) are fine. But nothing more than that. Learn SQL and handle it yourself. You will be thankful sooner or later.
- chrischapman 6y agoI'm really not sure why this was downvoted. I completely subscribe to this opinion. Been a SQL coder since 1997 (C# since 2003) and had my run in with ORMs in the last decade. There is no way I'd voluntarily use an ORM. I just don't see the benefit.
- blacktriangle 6y agoFinally made an account to respond to this. I completely agree with your take on ORMs and learning SQL. One thing that people get confused with about CoreData is treating it like an ORM; it is not. CoreData is an object persistence framework more in line with object databases than relational databases. The ability to use SQLite is just an implementation detail. It's like how Datomic can use a SQL db as a datastore however does not present data relationally. When porting apps back and forth between Android and iOS, the biggest thing I miss on Android is CoreData. CoreData is exceptional at what it does and its a shame that more iOS education doesn't focus more on CoreData.
- rimliu 6y agoCoreData is not ORM.
- cwoolfe 6y agoI was on a team that used Core Data and a team that used Realm instead. We had much more success with less headaches by using realm. https://realm.io/ https://realm.io/
- rudedogg 6y agoI used realm for a project, and don't think I would again. It's been a headache to deal with the dependency every Xcode release. They also refused to support SPM until the last minute. In hindsight I wish I would have learned Core Data instead.
- fatboy 6y agoIsn't there something funky with Realm where you can't have many-to-many relationships out of the box?
- dljsjr 6y agoI find it incredibly comical that one of the biggest repeated refrains in the parent article is "CoreData is not an ORM!" and yet the comment section is filled w/ folks talking about how ORMs are bad and how CoreData is a bad ORM. This article is very much worth reading.
- appleflaxen 6y ago> CoreData is not an ORM! Ok; I get that point from you. but the article says it's not a database, and that it is, in fact, > "Core Data is an “object graph and persistence framework”, which is basically like a fancy kind of object-relational mapping. " So I'm confused by everything in the article and the comments.
- sosborn 6y agoWhen CoreData first released, forums were full of people using it incorrectly, then complaining that it was buggy. It's good to see nothing has changed.
- gregkerzhner 6y agoThey forgot the most important rule of Core Data - just don’t use it!* The amount of problems and nuances it creates is simply not worth the functionality it provides. *If your app manages huge amounts of records on the device, then it might be worth it. But that’s not what many apps use Core Data for. Many apps use it to cache bits of data from the server and other local state. You don’t need a full blown ORM / database for this. Instead of wasting your time learning the obtuse Laws of Core Data, model your app state with some nice Codable structs, write it to disk, and then take the afternoon off.
- seanalltogether 6y agoOne more law about core data, don't edit objects until you're ready to commit them, and build a design pattern for other devs to copy that enforces this rule. In theory this is what parent child contexts are supposed to be used for, but the problem is that relationships break once an object is moved into a child context, so you end up with bigger headaches of gradually moving more and more dependent objects into the child context. If you forgo child context and still do edit in place, you're constantly playing whack-a-mole with data corruption as you or other devs forget to rollback data when a user cancels out of a flow.