Dear maintainer, looking at https://github.com/RxSwiftCommunity/RxCoreData/pull/23 and the RxDatasources implementation of cell updates, the Persistable protocol needs some more changes. Problem is it interferes with IdentifiableType protocol of RxDataSources.

Will provide updates for the examples as well after this is merged.

This builds on the existing pull request #10 (also thereby issue #9) and updates the dependencies to the latest RxSwift as well as fixing the example app (there is now a swift 3 RxDataSources)

I've also bumped the version number in the podspec and updated the readme.

Is this necessary to use iOS 9.1 as the minimum deployment target? As far as I know RxSwift and RxCocoa require a minimum dep. iOS 8.0 . Can we lower the deployment target to iOS 8 ? I'll be happy to send a PR to do so.

1. update RxSwift and RxCocoa versions in the podspec to 6.0.0
2. change directory from RxCoreDateExamples to RxCoreDataExamples (note Date vs Data)
3. ensure there is a Podfile for the examples
4. add the necessary pods to the Podfile for the examples
5. ensure the Examples projects builds and remove all errors

Issue

I had a performance issue using the rx_entities method. The fetch request that I have to execute is heavy and it blocks the Main thread, and as expected the bottleneck is try self.frc.performFetch(). So I created another context with the concurrency type PrivateQueueConcurrencyType and I called rx_entities using the new context but nothing the try self.frc.performFetch() was still executed on the Main Thread because I was calling rx_entities on the Main Thread.

Proposal

What do you think about wrapping the try self.frc.performFetch() and sendNextElement() with performBlock? Or even better to schedule rx_entities on the context thread.

This PR builds on my previous contributions and adds cross platform Carthage support to the project.

I've followed the convention used by RxOptional, Actions and other RxSwiftCommunity projects by having a scheme and target per platform. As annoying as it is adding any new source files to all 4 targets, it seems like it's not possible to have a single target and include all of the flavours of RxSwift - however, I'd be more than happy to be corrected.

Finally, I've removed _Pods.xcodeproj as it's a dead symbolic link.

I updated the dependencies to use the 3.0.0 releases of RxSwift/RxCocoa - along with RxDataSources 1.0.0 in the example app.

It threw up a couple of minor syntax changes: • creating AnonymousDisposables can now only be done via Disposables.create • self.tableView.rx.model(at: indexPath) needs the explicit "at" (this used in the example app)

With the build setting for ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES I've removed them again, erring on the side of stopping Cocoapods from complaining even though Xcode will disagree. You kinda can't win with this at the moment :/

Updated the version number (0.3.0 without the rc bit). The podspec lints ok for me with Cocoapods 1.1.1 so should be good to go.

Hi, guys I've already started some changes towards Swift 3.0 support. If you don't mind I would like to continue working on it :) So please add In Progress label

Hi and thank you for RxCoreData 😊

RxSwift has released version 6.0.0 and I am getting an error updating our main project to RxSwift 6.0.0 because RxCoreData is still on 5.x

Would it be possible to update RxCoreData to RxSwift 6.0?

Hey, I've just added an information to the readme that one is able to install RxCoreData via Carthage. I've thought it's not supported at first, but then I found out it is by simply trying it out. Maybe this clears it up a bit.

I'm still getting familiar with RxSwift, especially with regards to its memory management. I'm not clear on "what" the observer is. So in FetchedResultsControllerEntityObserver, it keeps a reference to observer so it can send onNext events in the delegate methods. Is this not a retain cycle, because observer is being held by the FetchedResultsControllerEntityObserver and also (I might be wrong here) by the Observable it's created in? Or is this one of those scenarios where all the references are being held "down-stream" so you don't really have a parent<--> child retain-cycle, just two references to a child.

In the Observable.create( (observer) -> Disposable) call, who "owns" the observer?

IMHO, mapping domain objects to NSManagedObject and vice-versa shouldn't be part of this library, main target is rx extensions of CoreData. (Mainly doing same as RxRealm)

Add notification based NSManagedObjectContext change observation.

This adds two extra reactive extension to NSManagedObjectContext:

1. Observable for any context changes
2. Observable for object change in context

This would allow us later to create an observable with NSFetchRequest which will be notification based instead of NSFetchedResultsController. Benefits would be that every time a relationship of a type is changed we can trigger next value.

I think @samscam initially created this repo, but hasn't been active lately. That's totally fin! Open source is all volunteer-based. But we should discuss future stewardship of this project.