More documentation around setting up a repo would be helpful

[oco-adam]

Hi Andrew,

First of all, thanks very much for the great work so far on this project!


However, being fairly new to Core Data I’m not sure exactly how you intend to set up and use this repo in a way that doesn’t block the main queue, whilst not hitting thread exceptions due to Core Data accessing objects on different threads.

So a few lines in the Readme or an example of a project where you set up Core data with TCA so that it can be used in the background would be great.

To give you a bit more idea of my particular use case:

I’m trying to move migrate a project (which uses TCA) over from Realm to Core Data and I’m struggling to get Core data to work (partly due to my lack of knowledge and partly due to the additional quirks of Core Data regarding thread safety), so I’m hoping your project can sidestep the issues I’m coming across.

Currently I have a non standard Realm set-up i.e. I am using it as a repository in a similar vein to this project, rather than with “live objects”. In this way I can offload requests to the background - I.e. I can say things like this in my reducers:

         environment.database
          .doRepoAction()
          .subscribe(on: environment.backgroundQueue)
          .receive(on: environment.mainQueue)
		…

So ideally I would like an example where you set up your core data repo in a way that frees up the main thread and can ideally be used in situations such as the above. All your tests seem to use the viewContext rather than a background context, so I would like to understand:

When you use this package, do you still need to use things like container.newBackgroundContext() and context.perform { }, and if so, can you please give a simple example of how you might do this?

Many thanks,
Adam

[roanutil]

Adam

Thank you for the question. For simplicity, the tests and README do make use of the viewContext. However, it would be best if at least the tests set a better example by using a private context in the repository.

I've pushed a branch that makes this change.
https://github.com/roanutil/CoreDataRepository/tree/non-main-queue
Please take a look and let me know if this helps.

When making changes to Core Data through the repository, you should NOT have to directly interact with a context or wrap any work in a perform or performAndWait closure. In the tests I do it manually sometimes to avoid testing the repository with the repository itself.

Making this change did reveal a bug where the repository internally did not wrap a save on the parent context within a performAndWait closure. So, that just goes to show what happens when we take shortcuts on tests.

Andrew

[oco-adam]

Hi Andrew,

Thanks very much for looking in to this.

Yes, the changes you have made to https://github.com/roanutil/CoreDataRepository/tree/non-main-queue help a lot.

By looking at Tests/CoreDataRepositoryTests/CoreDataXCTestCase I can get an idea as to how you intend on setting up a repository for use in the background - thanks!

However, in my opinion these details are really important, if not core to this project's value and it took me a few mins of digging around to find and digest them. So it might be an idea to include this setup in a small section in the readme if possible.

For example, a short section just before the CRUD section of the readme could explain how to set it up the repo on a background queue and therefore the CRUD section could then clarify how to use it on a background queue (i.e. that you don't need to worry about performAndWait etc, which I think is a real advantage of using this library btw!). E.g.

Setting up a Repository on a Background Queue

let backgroundQueue = DispatchQueue(label: "background", qos: .userInitiated)
  var repositoryContext: NSManagedObjectContext?
  backgroundQueue.sync {
       repositoryContext = container.newBackgroundContext()
       repositoryContext.automaticallyMergesChangesFromParent = true
  }
  let repository = CoreDataRepository(context: try repositoryContext)

CRUD

...

I think that what you've done here is really great, but could potentially reach more people by making this aspect a little clearer and easier to find - please let me know your thoughts on this.

Thanks again,
Adam

[roanutil]

Would you mind making a PR with the README changes you would like to see? I think those are reasonable changes but it would be easier to review a PR than try to collaborate in an issue.

[roanutil]

Feel free to re-open if you want to continue on this