When attempting to call 'delete' I am receiving a -[NSManagedObjectContext delete:]: unrecognized selector sent to instance 0x79e53be0.

Placing breakpoints in the extension, I can quickly see that the JSQCoreDataKit NSManagedObjectContext extension is NOT called, which makes it understandable why the above error as 'delete' is being called

Other included frameworks with extensions have worked ok... and I see that the example project works fine. No idea why these symbols are being lost, though a SO post sheds some light on the issue being known for 'generics'

General information

• Library version(s): 4.0.1
• OS version(s): iOS 9.3
• Devices/Simulators affected: iPhone 5 simulator
• Reproducible in the demo project (Yes/No): No
• Related issues: [http://stackoverflow.com/questions/24175596/swift-framework-does-not-include-symbols-from-extensions-to-generic-structs]

Expected behavior

Object is deleted

Actual behavior

-[NSManagedObjectContext delete:]: unrecognized selector sent to instance 0x79e53be0

Steps to reproduce

1. Include framework within the project.
2. Add framework to the appropriate Build Phases.
3. Call self.stack?.mainContext.delete(obj)

Prefer methods and properties to free functions.

Swift API Design Guidelines

~~Let's keep the free functions in place, but add extensions to types (which should call the free functions).~~

Update:*

• [x] extension on NSManagedObjectContext for delete
• [x] extension on NSManagedObjectContext for fetch
• [x] move resetStack to CoreDataStack

Pull request checklist

• [ √ ] All tests pass. Demo project builds and runs.
• [ √ ] I have resolved any merge conflicts.
• [ √ ] I have followed the coding style, and reviewed the contributing guidelines.

What's in this pull request?

For a current project, I needed to supply a custom NSPersistentStoreCoordinator subclass so I could support an encrypted backing store. This pull request adds the ability to supply an optional factory method to the CoreDataStackFactory that allows the user of the factory to do just that. I included test coverage and all tests pass.

Hey Jesse - was looking over the release-2.0 branch and noticed that the persistent store wasn't being added to the psc on a background thread. According to the new (preliminary) docs, they suggest you do so because it can take an unknown amount of time. Just thought I'd throw it out there.

As part of the initialization of Core Data, assign the adding of the persistent store (NSPersistentStore) to the persistent store coordinator (NSPersistentStoreCoordinator) to a background queue. That action can take an unknown amount of time, and performing it on the main queue can block the user interface, possibly causing the application to terminate.

https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Conceptual/CoreData/IntegratingCoreData.html#//apple_ref/doc/uid/TP40001075-CH9-SW1

And there sample implementation fwiw.

dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
        NSError *error = nil;
        NSPersistentStoreCoordinator *psc = [[self managedObjectContext] persistentStoreCoordinator];
        NSPersistentStore *store = [psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:options error:&error];
        NSAssert(store != nil, @"Error initializing PSC: %@\n%@", [error localizedDescription], [error userInfo]);
});

https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Conceptual/CoreData/InitializingtheCoreDataStack.html#//apple_ref/doc/uid/TP40001075-CH4-SW1

The current implementations in the createStackInBackground and createStack methods of the CoreDataStackFactory have some technically unnecessary limitations regarding the calling thread (precondition statements).

Creating queue based contexts with the NSPrivateQueueConcurrencyType and NSMainQueueConcurrencyType on any thread (including the main thread) is absolutely legit and valid.

As described in the NSManagedObjectContext Class Reference only contexts using the deprecated confinement pattern must be created and used from a single thread. I.e. those contexts are no longer valid if the thread to which the context was bound during the init phase ends. Queue based contexts on the other hand must not be used with anything else but the performBlock and performBlockAndWait which automatically ensures that the operations are run in a correct context (thread).

That being said:

• the precondition in createStack of CoreDataStackFactory is unnecessary. Calling this method asynchronously would be totally fine, both backgroundContext and the mainContext would work as expected.
• the precondition in createStackInBackground of CoreDataStackFactory is also unnecessary.
• CoreDataFunctions and the resetStack have the same limitation.

It does however make sense for some of the mentioned methods to be called asynchronously (or to be called on the main queue) even though there's no technical requirement to do so. If the mentioned limitations are intended because it helps the UI to stay responsive then this should be at least documented. Otherwise it would be a good thing to give developers the freedom to use those methods on any queue they want for whatever reason there may be.

Pull request checklist

• [x] All tests pass. Demo project builds and runs.
• [x] I have resolved any merge conflicts.
• [x] I have followed the coding style, and reviewed the contributing guidelines.

This fixes issue #100

What's in this pull request?

Added Search Framework Path to the ExampleModel project to locate the JSQCoreDataKit.framework built during carthage build

Pull request checklist

• [x] All tests pass. Demo project builds and runs.
• [x] I have resolved any merge conflicts.
• [x] I have followed the coding style, and reviewed the contributing guidelines.

This fixes issue #___.

What's in this pull request?

Uses a cleaner FetchRequest.

General information

• Library version(s): 2.2.0

Description

Hi, we're using your excellent framework, and I noticed that the saving performed on didReceiveChildContextDidSaveNotification is using performBlockAndWait by default (see here).

This may cause deadlocks, for example, if I replace the implementation of didTapAddButton in the ExampleApp with:

    func didTapAddButton(sender: UIBarButtonItem) {
        let childContext = stack.childContext()
        childContext.performBlock {
            Company.newCompany(childContext)
            saveContext(childContext, wait: false)
        }

        for i in 1...10 {
            childContext.performBlockAndWait { }
            print(i)
        }
    }

It deadlocks.. I iterate 10 times just to make sure, but it deadlocks on the 2nd time.

The problem is that there's an implicit waiting when using saveContext(childContext, wait: false), i.e. the childContext thread is waiting for the mainContext to save..

Why not use a different mechanism for the parent's context saving, so that the waiting behaviour will be preserved?

Thanks in advance, Amitai.

Since Example.xcodeproj and JSQCoreDataKit.xcodeproj are at the same level, Carthage builds ExampleModel.framework which is undesired. Moving /Example into /JSQCoreDataKit seems to me to be the best way to resolve this if you have no objections.

New issue checklist

• [x] I have read the README and docs.
• [x] I have reviewed the contributing guidelines.
• [x] I have searched existing issues and this is not a duplicate.

General information

• Library version(s): 6.0.0
• OS version(s): MacOS 10.12
• Devices/Simulators affected: No
• Reproducible in the demo project (Yes/No): No
• Related issues: None

Expected behavior

• No "Convert to Current Swift Syntax" dialog should appear after installing cocoapod
• Project should build

Actual behavior

• "Convert to Current Swift Syntax" dialog appears after installing cocoapod
• Project does not build. Error that JSQCoreDataKit is using legacy Swift.

Steps to reproduce

Create a project using Swift 3. Install latest cocoapod 6.0.0 Open project workspace Dialog opens to ask to "Convert to Current Swift Syntax"

Crash log? Screenshots? Videos? Sample project?

This can be fixed by adding...

"pod_target_xcconfig": { "SWIFT_VERSION": "3.0" }

to the podspec but I don't know the syntax of the podspec file that you are using. I am used to the old syntax so not sure how it works with your podspec.

Once this is added to the podspec it should quiet the dialog.

Pull request checklist

• [x] All tests pass. Demo project builds and runs.
• [x] I have resolved any merge conflicts.
• [x] I have rebased on develop squashed my commits into 1 commit.
• [x] I have followed the coding style, and reviewed the contributing guidelines.

This fixes issue #46 .

What's in this pull request?

Added a top level function that performs progressive migrations. The function is a bit large, it could be broken down but not sure what's your preference @jessesquires .

Can wrap this to be reusable:

https://useyourloaf.com/blog/async-core-data-testing/

(See also: "verifySaveSucceeded/Failed" helpers from my existing projects)

As of Xcode 13, plists can be generated automatically.

We can delete them from the framework targets and test targets.

Also update Package.swift

https://useyourloaf.com/blog/xcode-13-missing-info.plist/

Not sure why this is happening yet, but need to fix.

Hypothesis: some tests write to disk. maybe a disk access permissions issues?

Possible solution: disable those tests for macOS