Editing objects in UnsafeDataTransaction #104

New Issue

adam · 2025-12-29T15:24:42+01:00

adam commented

2025-12-29 15:24:42 +01:00

Originally created by @mrichtsfeld on GitHub (Nov 28, 2016).

I need to use UnsafeDataTransaction for editing in some views. I change values from the UI which get stored to the object within the transaction. However the UnsafeDataTransaction uses its own queue. When working with CoreData without CoreStore it is necessary to edit an object with the queue of its NSManagedObjectContext via:

myObject.managedObjectContext?.performAndWait { // do your changes here }

I haven't found anything to do that on the UnsafeDataTransaction. Is it intended do be done via performAndWait on the managed object's context, or directly on the UnsafeDataTransaction? If there is any implementation necessary to do this I can fork and do it. I only want to discuss the right way to do it.

Btw. great framework, keep up the good work 👍

Originally created by @mrichtsfeld on GitHub (Nov 28, 2016). I need to use `UnsafeDataTransaction` for editing in some views. I change values from the UI which get stored to the object within the transaction. However the `UnsafeDataTransaction` uses its own queue. When working with CoreData without CoreStore it is necessary to edit an object with the queue of its `NSManagedObjectContext` via: `myObject.managedObjectContext?.performAndWait { // do your changes here }` I haven't found anything to do that on the `UnsafeDataTransaction.` Is it intended do be done via `performAndWait` on the managed object's context, or directly on the `UnsafeDataTransaction`? If there is any implementation necessary to do this I can fork and do it. I only want to discuss the right way to do it. Btw. great framework, keep up the good work :+1:

adam closed this issue

2025-12-29 15:24:42 +01:00

adam commented

2025-12-29 15:24:43 +01:00

@JohnEstropia commented on GitHub (Nov 28, 2016):

The UnsafeDataTransaction inherits a queue from BaseDataTransaction, but it never uses it. Using UnsafeDataTransactions means you explicitly want to bypass CoreStore's queueing mechanism.

While I recommend you use AsynchronousDataTransactions or SynchronousDataTransactions instead, if you really need to go without queueing then you are free to edit objects directly (at your discretion) or use Core Data's standard perform methods.

@JohnEstropia commented on GitHub (Nov 28, 2016): The UnsafeDataTransaction inherits a queue from BaseDataTransaction, but it **never** uses it. Using UnsafeDataTransactions means you explicitly want to bypass CoreStore's queueing mechanism. While I recommend you use AsynchronousDataTransactions or SynchronousDataTransactions instead, if you really need to go without queueing then you are free to edit objects directly (at your discretion) or use Core Data's standard `perform` methods.

adam commented

2025-12-29 15:24:43 +01:00

@mrichtsfeld commented on GitHub (Nov 28, 2016):

Thanks for your quick answer and the clarification on the perform methods.

Regarding the AsynchronousDataTransactions or SynchronousDataTransactions I would also prefer using these, but in my case I pass an object to a view for editing within an UnsafeDataTransaction. As soon as editing is finished I save/commit it. Maybe there is something I missed, but as far as I understand this cannot we accomplished either by synchronous or asynchronous data transaction, right? The first one is anyway using the current thread to do the work and the second uses a background queue, but there is still no way to keep it open for a while and commit it at the end, right?

@mrichtsfeld commented on GitHub (Nov 28, 2016): Thanks for your quick answer and the clarification on the `perform` methods. Regarding the AsynchronousDataTransactions or SynchronousDataTransactions I would also prefer using these, but in my case I pass an object to a view for editing within an UnsafeDataTransaction. As soon as editing is finished I save/commit it. Maybe there is something I missed, but as far as I understand this cannot we accomplished either by synchronous or asynchronous data transaction, right? The first one is anyway using the current thread to do the work and the second uses a background queue, but there is still no way to keep it open for a while and commit it at the end, right?

adam commented

2025-12-29 15:24:43 +01:00

@JohnEstropia commented on GitHub (Nov 28, 2016):

I see, yes UnsafeDataTransaction is a good use for this. If so, as long as there is no other transactions working on the same data while the UnsafeDataTransaction is in use then there shouldn't be a need to worry about performBlock methods.

@JohnEstropia commented on GitHub (Nov 28, 2016): I see, yes UnsafeDataTransaction is a good use for this. If so, as long as there is no other transactions working on the same data while the UnsafeDataTransaction is in use then there shouldn't be a need to worry about performBlock methods.

adam commented

2025-12-29 15:24:43 +01:00

@mrichtsfeld commented on GitHub (Nov 28, 2016):

Great, thanks for you help and clarifications 👍

@mrichtsfeld commented on GitHub (Nov 28, 2016): Great, thanks for you help and clarifications :+1:

adam referenced this issue

2025-12-29 15:32:15 +01:00

[PR #104] [MERGED] Fixes #98 (deadlock when merge happens while main queue is querying) #459

Sign in to join this conversation.

Branches Tags

develop

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#104