starred/CoreStore-JohnEstropia
1
0
Fork 0
mirror of https://github.com/JohnEstropia/CoreStore.git synced 2026-03-20 08:33:53 +01:00
Code Issues 95 Packages Projects Releases 10 Wiki Activity

Merge branch 'develop'

Browse Source
This commit is contained in:
John Rommel Estropia
2016-02-17 02:06:57 +09:00
parent 405e861907 8c8953c507
commit 0c4e55f061
91 changed files with 2678 additions and 1912 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
README.md
View File

@@ -14,18 +14,18 @@ Unleashing the real power of Core Data with the elegance and safety of Swift
## What CoreStore does better:
- Heavily supports multiple persistent stores per data stack, just the way *.xcdatamodeld* files are designed to. CoreStore will also manage one data stack by default, but you can create and manage as many as you need.
- Incremental Migrations! Just tell the data stack the sequence of model versions and CoreStore will automatically use incremental migrations if needed on stores added to that stack.
- Ability to plug-in your own logging framework
- Gets around a limitation with other Core Data wrappers where the entity name should be the same as the `NSManagedObject` subclass name. CoreStore loads entity-to-class mappings from the managed object model file, so you are free to name them independently.
- Provides type-safe, easy to configure observers to replace `NSFetchedResultsController` and KVO
- Exposes API not just for fetching, but also for querying aggregates and property values
- Makes it hard to fall into common concurrency mistakes. All `NSManagedObjectContext` tasks are encapsulated into safer, higher-level abstractions without sacrificing flexibility and customizability.
- Exposes clean and convenient API designed around Swift’s code elegance and type safety.
- Documentation! No magic here; all public classes, functions, properties, etc. have detailed Apple Docs. This README also introduces a lot of concepts and explains a lot of CoreStore's behavior.
- **New in 1.3.0:** Efficient importing utilities!
- **Heavily supports multiple persistent stores per data stack**, just the way *.xcdatamodeld* files are designed to. CoreStore will also manage one data stack by default, but you can create and manage as many as you need.
- **Incremental Migrations!** Just tell the data stack the sequence of model versions and CoreStore will automatically use incremental migrations if needed on stores added to that stack.
- Ability to **plug-in your own logging framework**
- Gets around a limitation with other Core Data wrappers where the entity name should be the same as the `NSManagedObject` subclass name. CoreStore loads entity-to-class mappings from the managed object model file, so you are **free to name entities and their class names independently**.
- Provides type-safe, easy to configure **observers to replace `NSFetchedResultsController` and KVO**
- Exposes **API not just for fetching, but also for querying aggregates and property values**
- Makes it hard to fall into common concurrency mistakes. All `NSManagedObjectContext` tasks are encapsulated into **safer, higher-level abstractions** without sacrificing flexibility and customizability.
- Exposes clean and convenient API designed around **Swift’s code elegance and type safety**.
- **Documentation!** No magic here; all public classes, functions, properties, etc. have detailed Apple Docs. This README also introduces a lot of concepts and explains a lot of CoreStore's behavior.
- **Efficient importing utilities!**
**[Or vote for the next feature!](http://goo.gl/RIiHMP)**
**[Vote for the next feature!](http://goo.gl/RIiHMP)**
@@ -259,7 +259,7 @@ class MyViewController: UIViewController {
So far we have only seen `addSQLiteStoreAndWait(...)` used to initialize our persistent store. As the method name's "AndWait" suffix suggests, this method blocks so it should not do long tasks such as store migrations (in fact CoreStore won't even attempt to, and any model mismatch will be reported as an error). If migrations are expected, the asynchronous variant `addSQLiteStore(... completion:)` method should be used instead:
```swift
do {
let progress: NSProgress = try dataStack.addSQLiteStore(
let progress: NSProgress? = try dataStack.addSQLiteStore(
fileName: "MyStore.sqlite",
configuration: "Config2",
completion: { (result) -> Void in
@@ -566,7 +566,7 @@ CoreStore.beginAsynchronous { (transaction) -> Void in
From(MyPersonEntity),
Where("name", isEqualTo: "Jane Smith")
)
jane.friends = NSSet(array: transactin.fetchExisting(peopleIDs)!)
jane.friends = NSSet(array: transaction.fetchExisting(peopleIDs)!)
// ...
}
```
@@ -714,7 +714,7 @@ class func uniqueIDFromImportSource(source: ImportSource, inTransaction transact
```
For `ImportableUniqueObject`, the extraction and assignment of values should be implemented from the `updateFromImportSource(...)` method. The `didInsertFromImportSource(...)` by default calls `updateFromImportSource(...)`, but you can separate the implementation for inserts and updates if needed.
You can then call create/update an object by calling a transaction's `importUniqueObject(...)` method:
You can then create/update an object by calling a transaction's `importUniqueObject(...)` method:
```swift
CoreStore.beginAsynchronous { (transaction) -> Void in
let json: [String: AnyObject] = // ...
@@ -1162,8 +1162,8 @@ let person2 = self.monitor[1, 2]
# Roadmap
- Data importing utilities for transactions
- Support iCloud stores
- CoreSpotlight auto-indexing (experimental)
# Installation
@@ -1180,9 +1180,14 @@ pod 'CoreStore'
This installs CoreStore as a framework. Declare `import CoreStore` in your swift file to use the library.
### Install with Carthage
In your `Cartfile`, add
```
github "JohnEstropia/CoreStore" >= 1.3.0
github "JohnEstropia/GCDKit" >= 1.1.5
github "JohnEstropia/CoreStore" >= 1.4.4
github "JohnEstropia/GCDKit" >= 1.1.7
```
and run
```
carthage update
```
### Install as Git Submodule