All Versions
15
Latest Version
Avg Release Cycle
41 days
Latest Release
10 days ago

Changelog History
Page 1

  • v7.0.3

    January 08, 2020
  • v7.0.2

    December 23, 2019
  • v7.0.1

    October 25, 2019
  • v7.0.0

    October 22, 2019

    ⚑️ ⚠️This update will break current code. Make sure to read the changes below:

    πŸ’₯ Breaking Changes

    πŸš€ Starting version 7.0.0, CoreStore will be using a lot of Swift 5.1 features, both internally and in its public API. You can keep using the last 6.3.2 release if you still need Swift 5.0.

    πŸ—„ Deprecations

    βͺ The CoreStore-namespaced API has been deprecated in favor of DataStack method calls. If you are using the global utilities such as CoreStore.defaultStack and CoreStore.logger, a new CoreStoreDefaults namespace has been provided:

    • βͺ CoreStore.defaultStack -> CoreStoreDefaults.dataStack
    • βͺ CoreStore.logger -> CoreStoreDefaults.logger
    • βͺ CoreStore.addStorage(...) -> CoreStoreDefaults.dataStack.addStorage(...)
    • βͺ CoreStore.fetchAll(...) -> CoreStoreDefaults.dataStack.fetchAll(...)
    • etc.

    If you have been using your own properties to store DataStack references, then you should not be affected by this change.

    πŸ†• New features

    Backwards-portable DiffableDataSources implementation

    UITableViews and UICollectionViews now have a new ally: ListPublishers provide diffable snapshots that make reloading animations very easy and very safe. Say goodbye to UITableViews and UICollectionViews reload errors!

    🍎 DiffableDataSource.CollectionView (iOS and macOS) and DiffableDataSource.TableView (iOS)

    self.dataSource = DiffableDataSource.CollectionView\<Person\>( collectionView: self.collectionView, dataStack: CoreStoreDefaults.dataStack, cellProvider: { (collectionView, indexPath, person) inlet cell = collectionView.dequeueReusableCell(withReuseIdentifier: "PersonCell") as! PersonCell cell.setPerson(person) return cell } )
    

    ⚑️ This is now the recommended method of reloading UITableViews and UICollectionViews because it uses list diffing to update your list views. This means that it is a lot less prone to cause layout errors.

    ListPublisher and ListSnapshot

    ⚑️ ListPublisher is a more lightweight counterpart of ListMonitor. Unlike ListMonitor, it does not keep track of minute inserts, deletes, moves, and updates. It simply updates its snapshot property which is a struct storing the list state at a specific point in time. This ListSnapshot is then usable with the DiffableDataSource utilities (See section above).

    self.listPublisher = dataStack.listPublisher( From\<Person\>() .sectionBy(\.age") { "Age \($0)" } // sections are optional .where(\.title == "Engineer") .orderBy(.ascending(\.lastName)))self.listPublisher.addObserver(self) { [weak self] (listPublisher) in self?.dataSource?.apply( listPublisher.snapshot, animatingDifferences: true )}
    

    ListSnapshots store only NSManagedObjectIDs and their sections.

    ObjectPublisher and ObjectSnapshot

    ObjectPublisher is a more lightweight counterpart of ObjectMonitor. Unlike ObjectMonitor, it does not keep track of per-property changes. You can create an ObjectPublisher from the object directly:

    let objectPublisher: ObjectPublisher\<Person\> = person.asPublisher(in: dataStack)
    

    or by indexing a ListPublisher's ListSnapshot:

    let objectPublisher = self.listPublisher.snapshot[indexPath]
    

    The ObjectPublisher exposes a snapshot property which returns an ObjectSnapshot, which is a lazily generated struct containing fully-copied property values.

    objectPublisher.addObserver(self) { [weak self] (objectPublisher) inlet snapshot: ObjectSnapshot\<Person\> = objectPublisher.snapshot// handle changes}
    

    This snapshot is completely thread-safe, and any mutations to it will not affect the actual object.

    Intent-based Object representations

    βͺ CoreStore is slowly moving to abstract object utilities based on usage intent.
    βͺ NSManageObject',CoreStoreObject,ObjectPublisher, andObjectSnapshotall conform to theObjectRepresentation` protocol, which allows conversion of each type to another:

    public protocol ObjectRepresentation { associatedtype ObjectType : CoreStore.DynamicObjectfunc objectID() -\> ObjectType.ObjectID func asPublisher(in dataStack: DataStack) -\> ObjectPublisher\<ObjectType\> func asReadOnly(in dataStack: DataStack) -\> ObjectType?func asEditable(in transaction: BaseDataTransaction) -\> ObjectType?func asSnapshot(in dataStack: DataStack) -\> ObjectSnapshot\<ObjectType\>?func asSnapshot(in transaction: BaseDataTransaction) -\> ObjectSnapshot\<ObjectType\>?}
    

    ObjectMonitor being excluded in this family was intentional; its initialization is complex enough to be an API of its own.

  • v6.3.2

    August 27, 2019
  • v6.3.1

    April 04, 2019
  • v6.3.0

    April 01, 2019
    • πŸ— CoreStore now builds on Swift 5 and Xcode 10.2
    • βͺ SetupResult<T>, MigrationResult, and AsynchronousDataTransaction.Result<T> have all been converted into typealiases for Swift.Result<T, CoreStoreError>. The benefit is we can now use the utility methods on Swift.Result such as map(), mapError(), etc. Their Objective-C counterparts (CSSetupResult, etc.) remain available and can still be used as before.
    • πŸ—„ Bunch of deprecated/obsoleted stuff deleted
    • πŸ›  CoreData iCloud support had been deprecated for a while now and CoreStore finally removes its support in this version. If you wish to continue using it please continue to use the 6.2.x versions but it will be unlikely to get bugfixes from here on out so please try to migrate your app's data as soon as possible (iOS and macOS already had this deprecated for years)
  • v6.2.1

    February 28, 2019
  • v6.2.0

    February 28, 2019
  • v6.1.0

    February 12, 2019