Support non-CoreData #171

New Issue

2025-12-29T18:24:01+01:00

adam commented

2025-12-29 18:24:01 +01:00

Originally created by @akac on GitHub (Sep 20, 2017).

I love CoreStore. It works very well and it fixes pretty much every major issue I have with CoreData. While I personally have no issue with using CoreData as the foundation of CoreStore, what I keep thinking is that CoreStore is designed in a way that it really shouldn't care what the underlying store is.

Perhaps its Realm. Perhaps its CoreData. Perhaps its some other system. Pluggable modules almost. That would make CoreStore future-proof.

Just a thought.

Originally created by @akac on GitHub (Sep 20, 2017). I love CoreStore. It works very well and it fixes pretty much every major issue I have with CoreData. While I personally have no issue with using CoreData as the foundation of CoreStore, what I keep thinking is that CoreStore is designed in a way that it really shouldn't care what the underlying store is. Perhaps its Realm. Perhaps its CoreData. Perhaps its some other system. Pluggable modules almost. That would make CoreStore future-proof. Just a thought.

adam commented

2025-12-29 18:24:02 +01:00

@JohnEstropia commented on GitHub (Sep 22, 2017):

Thanks for giving this much thought on CoreStore :) I appreciate ideas like these.

Backend abstraction is actually one of the motivations of the new CoreStoreObject API, but on the storage layer (sqlite), not the ORM layer (Core Data). The thing is, Core Data supports any database backend and in fact 2 years ago I wrote a Realm-backed Core Data stack.

Core Data is actually one of the best ORMs out there, and I don't know if it would be realistic to reimplement faulting, notifications (fetchedResultsController), migrations, etc. I don't know if we can abstract all that to a worthy level. Realm for example took more than a year to get to the level of features they have today, and that's already their own in-house architecture.

With regards to future-proofing, I don't know if there's a better guarantee here than using an API that Apple itself created, maintains and uses. That said, if there's an open-source ORM abstraction that would exceed the utility of Core Data, I'll be happy to make CoreStore depend on that instead.

@JohnEstropia commented on GitHub (Sep 22, 2017): Thanks for giving this much thought on CoreStore :) I appreciate ideas like these. Backend abstraction is actually one of the motivations of the new `CoreStoreObject` API, but on the storage layer (sqlite), not the ORM layer (Core Data). The thing is, Core Data supports any database backend and in fact 2 years ago [I wrote a Realm-backed Core Data stack](https://github.com/eure/RealmIncrementalStore). Core Data is actually one of the best ORMs out there, and I don't know if it would be realistic to reimplement faulting, notifications (fetchedResultsController), migrations, etc. I don't know if we can abstract all that to a worthy level. Realm for example took more than a year to get to the level of features they have today, and that's already their own in-house architecture. With regards to future-proofing, I don't know if there's a better guarantee here than using an API that Apple itself created, maintains and uses. That said, if there's an open-source ORM abstraction that would exceed the utility of Core Data, I'll be happy to make CoreStore depend on that instead.

Sign in to join this conversation.

Branches Tags

develop

prototype/swift6

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore-JohnEstropia#171