Asserting when CoreData thread debugging is enabled #23

New Issue

2025-12-29T18:21:33+01:00

adam commented

2025-12-29 18:21:33 +01:00

Originally created by @JoeMatt on GitHub (Dec 18, 2015).

When activating the CoreData launch flag -com.apple.CoreData.ConcurrencyDebug 1 all of the included tests assert at the first managed object creation attempt.

Originally created by @JoeMatt on GitHub (Dec 18, 2015). When activating the CoreData launch flag `-com.apple.CoreData.ConcurrencyDebug 1` all of the included tests assert at the first managed object creation attempt.

adam closed this issue

2025-12-29 18:21:33 +01:00

adam commented

2025-12-29 18:21:34 +01:00

@JohnEstropia commented on GitHub (Dec 18, 2015):

Thanks for the feedback!

Yup, this is expected to happen. The com.apple.CoreData.ConcurrencyDebug flag lets Core Data tell you when the managed context is accessed from any queue other than its own, which includes CoreStore's transactions' queues (beginAsynchronous(), etc).

CoreStore already guarantees safety for you by making the Main Context read-only, and by only allowing updates to be made within transactions. You should be safe even without the ConcurrencyDebug flag (as long as you don't do hacky things).

I'll close this for now but feel free to ask if you have other questions :)

@JohnEstropia commented on GitHub (Dec 18, 2015): Thanks for the feedback! Yup, this is expected to happen. The `com.apple.CoreData.ConcurrencyDebug` flag lets Core Data tell you when the managed context is accessed from any queue other than its own, which includes CoreStore's transactions' queues (`beginAsynchronous()`, etc). CoreStore already guarantees safety for you by making the Main Context read-only, and by only allowing updates to be made within transactions. You should be safe even without the ConcurrencyDebug flag (as long as you don't do hacky things). I'll close this for now but feel free to ask if you have other questions :)

adam commented

2025-12-29 18:21:34 +01:00

@JoeMatt commented on GitHub (Dec 18, 2015):

Would storing the managed object returned from a synchronous fetch as a Swift computed property be "hacky"

Trying to debug why we see random faults and that's about the strangest thing I think we're doing.

@JoeMatt commented on GitHub (Dec 18, 2015): Would storing the managed object returned from a synchronous fetch as a Swift computed property be "hacky" Trying to debug why we see random faults and that's about the strangest thing I think we're doing.

adam commented

2025-12-29 18:21:34 +01:00

@JohnEstropia commented on GitHub (Dec 18, 2015):

Do you mean something like this?

self.object = CoreStore.fetchOne(...) // or datastack.fetch...

If so then it should be fine.

I'm also curious what you meant by "random faults". If you are editing the object from inside a transaction, the object stored in the property is expected to refetch its new values (and is probably what you are observing).

@JohnEstropia commented on GitHub (Dec 18, 2015): Do you mean something like this? ``` swift self.object = CoreStore.fetchOne(...) // or datastack.fetch... ``` If so then it should be fine. I'm also curious what you meant by "random faults". If you are editing the object from inside a transaction, the object stored in the property is expected to refetch its new values (and is probably what you are observing).

Sign in to join this conversation.

Branches Tags

develop

prototype/swift6

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore-JohnEstropia#23