@lyricsboy I chatted with @jgallagher about this idea of throwing and returning error types in a result and he suggested I make the NSURL a part of the StackType enum itself.

I opted for an implicitly unwrapped optional so that a default URL can still be filled in if you don't want to specify a desired URL. This also allows the construct method's stack type parameter to also be optional.

I stubbed in todo statements for the two methods that were assuming SQLIte store types. If you like this solution I'll go back and handle those cases.

Any idea on where's the issue in this crash?

Thread : Crashed: NSManagedObjectContext 0x15462eaa0: Background Worker Context
0  libswiftCore.dylib             4317556504 usesNativeSwiftReferenceCounting_unowned(void const*) + 156
1  libswiftCore.dylib             4317557536 swift_unknownWeakRelease + 36
2  BNRCoreDataStack               4305106224 _TFFE16BNRCoreDataStackCSo22NSManagedObjectContext11saveContextFS0_FTGSqFOS_13SuccessResultT___T_U_FGSqFS1_T__T_ + 268
3  CoreData                       6501320960 developerSubmittedBlockToNSManagedObjectContextPerform + 196
4  libdispatch.dylib              6860510888 _dispatch_client_callout + 16
5  libdispatch.dylib              6860560108 _dispatch_queue_drain + 864
6  libdispatch.dylib              6860525996 _dispatch_queue_invoke + 464
7  libdispatch.dylib              6860510888 _dispatch_client_callout + 16
8  libdispatch.dylib              6860569408 _dispatch_root_queue_drain + 2140
9  libdispatch.dylib              6860567260 _dispatch_worker_thread3 + 112

I can't find what called save context. It's a fabric remote crash report.

Addresses issues #7 and #11 by opting to create a single nested MOC style stack with a method for creating a separate MOC with its own persistent store coordinator for handling batch type operations. Considerations will be documented in the README with the stack type diagrams and some examples in the sample project. #9 was fixed by removing that unnecessary class.

@jgallagher, @zwaldowski, @lyricsboy, @randomstep if any of you have time please take a look at this PR as a good time for an overall code review of the project since it hasn't had many additional eyes on it. Thanks

Question

Hi, I really enjoy using this framework, but I have something unclear about batch update.

The test project goes here. CoreDataTest.zip

I have created CoreDataStack in ViewController.swift and seed initial data like this.

private func seedInitData(stack:CoreDataStack){
        let moc = stack.newChildContext()
        do {
            try moc.performAndWaitOrThrow {
                let books = ["Book 1", "Book 2", "Book3"]
                for bookTitle in books {
                    let book = Book(managedObjectContext: moc)
                    book.title = bookTitle
                    book.isRent = false
                }
                try moc.saveContextAndWait()
            }
        } catch {
            print("Error creating initial data: \(error)")
        }
    }

After that did some testing on testStack() function in NewViewController.swift file.

func testStack(){
        let context = stack.newChildContext(concurrencyType: .PrivateQueueConcurrencyType, name: "batchWorker")
        let batchRequest = NSBatchUpdateRequest(entityName: "Book")
        batchRequest.propertiesToUpdate = ["isRent" : true]
        batchRequest.resultType = .UpdatedObjectIDsResultType
        do{

            // First, try to fetch all book object from core data.
            let objs = try context.executeFetchRequest(NSFetchRequest(entityName: "Book"))
            print("--------------Book objects before performing batch updates-----------")
            objs.forEach{
                let book = $0 as! Book
                // It should show false
                print("title : \(book.title), Rent = \(book.isRent)")
            }
            let batchResult = try context.executeRequest(batchRequest) as! NSBatchUpdateResult
            let objectIDS = batchResult.result as! [NSManagedObjectID]

            print("\n\n--------------After performing batch request & refreshObject-----------")
            objectIDS.forEach{
                let object = context.objectWithID($0) as! Book
                context.refreshObject(object, mergeChanges: false)

                // I think this should show true, but showing false now (So not changed)
                print("title : \(object.title), isRent : \(object.isRent)")
            }
        }catch{}
    }

Output Log

--------------Book objects before performing batch updates-----------
title : Optional("Book 2"), Rent = Optional(0)
title : Optional("Book 1"), Rent = Optional(0)
title : Optional("Book3"), Rent = Optional(0)


--------------After performing batch request & refreshObject-----------
title : Optional("Book 2"), isRent : Optional(0)
title : Optional("Book 1"), isRent : Optional(0)
title : Optional("Book3"), isRent : Optional(0)

I think after batch request is performed, it should show true. But it's showing false. Is this right behaviour or did I understand wrong?

It will be appreciated if anyone can help me.

Summary of Changes

• managedObjectModel is now a stored property which makes storing bundle and modelName unnecessary
• private init(modelName: String, bundle: Bundle, persistentStoreCoordinator: NSPersistentStoreCoordinator, storeType: StoreType) becomes a convenience initalizer
• private init(model: NSManagedObjectModel, persistentStoreCoordinator: NSPersistentStoreCoordinator, storeType: StoreType) becomes the default initializer

Feature Request

What would you like to see that is not available?

I have created my Model Objects with MoGenerator. When I make one of those generated classes implement CoreDataModelable, I get an error: /Model/Custom/Region.swift:7:20: Getter for 'entityName' with Objective-C selector 'entityName' conflicts with method 'entityName()' from superclass '_Region' with the same Objective-C selector

Question

Would it be a better idea to put all those very usefull functions in a straightforward: extension NSManagedObject { }

Expected behavior

Either way, I would like to be able to use the useful functions you implemented in CoreDataModelable.

Actual behavior

Compile error: Getter for 'entityName' with Objective-C selector 'entityName' conflicts with method 'entityName()' from superclass '_Region' with the same Objective-C selector

Additional Context

Xcode 7.3.1, Mogenerator 1.29, BNRCoreDataStack 1.2.5, Swift 2.2.

Thanks for contributing to the CoreDataStack!

Summary of Changes

We may be experiencing issues with starvation of global queues, since in our particular use case we spawn rather a lot of batch contexts. Please see example stack trace attach to reply. We appear to have a lot of threads stuck in -[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:].

It seems reasonable enough to just serialise stack creation, which is not possible using a global queue. So, simply add a serial queue property and make the necessary interface changes. I left the global queue and the default argument as well.

Please let me know what you think.

It is pretty common inside a TableViewController's init or viewDidLoad method to have initialisation code like the following:

override func viewDidLoad() {
  super.viewDidLoad()
  CoreDataStack.constructSQLiteStack(withModelName: "SomeName") { outcome in
    print(NSThread.isMainThread())     // false
    switch outcome {
      case .Failure(let error)        : print(error)
      case .Success(let coreDataStack):
        self.coreDataStack = coreDataStack
        self.tableView.reloadData()    // crash
    }
  }  
}

This code will crash however because the callback is executed on a background thread (created by setupSQLiteBackedCoordinator.

Unless I missed something, it seems to me it would be less confusing if the callback was executed on the main thread. After all, once the stack has been set up why remain in the background thread?

A pretty simple fix would be to just wrap the callback calls inside constructSQLiteStack:

    dispatch_async(dispatch_get_main_queue(), { 
      callback(.Success(stack))  // or callback(.Failure(error))
    })

Starting in Swift 3.1, the optimizer is free to introduce incorrect optimizations for the former implementation.

Before:

public func performAndWaitOrThrow<Return>(_ body: () throws -> Return) rethrows -> Return {
        func impl(execute work: () throws -> Return, recover: (Error) throws -> Void) rethrows -> Return {
            var result: Return!
            var error: Error?

            // performAndWait is marked @escaping as of iOS 10.0.
            // swiftlint:disable type_name
            typealias Fn = (() -> Void) -> Void
            let performAndWaitNoescape = unsafeBitCast(self.performAndWait, to: Fn.self)
            performAndWaitNoescape {
                do {
                    result = try work()
                } catch let e {
                    error = e
                }
            }

            if let error = error {
                try recover(error)
            }

            return result
        }

        return try impl(execute: body, recover: { throw $0 })
    }

After:

 public func performAndWaitOrThrow<Return>(_ body: () throws -> Return) rethrows -> Return {
        return try withoutActuallyEscaping(body) { (work) in
            var result: Return!
            var error: Error?

            performAndWait {
                do {
                    result = try work()
                } catch let e {
                    error = e
                }
            }

            if let error = error {
                throw error
            } else {
                return result
            }
        }
    }

Feature Request

Make sure the entity name comparison in EntityMonitor does not fail as a result of the module name. Utilize NSClassFromString to get a string for comparison.

Expected behavior

Entity matching class should not fail based on module name when creating an EntityMonitor

Actual behavior

It fails the match and creates a precondition failure.

Sorry my previous issue was very thin in information.

I've managed to reproduce the issue in the attached project. I'm not sure if the way I used the init method is still valid. The method is marked deprecated for iOS10 but the project I'm on is targeting iOS9. And I get no build errors so it should be fine?

So I might missed something when migrating to the new version? I moved from swift 2 to swift 3. And from CoreDataStack 1.2.5 to 2.0.2.

BNRTest.zip