Observing changes by a single transaction #37

New Issue

adam · 2025-12-29T15:22:46+01:00

adam commented

2025-12-29 15:22:46 +01:00

Originally created by @jamesbebbington on GitHub (Feb 4, 2016).

Is there a way of compiling a changeset of CRUD operations that occurred within a given transaction? I see that commit() returns a SaveResult but that doesn't look to say much about the operations that occurred. Would it be difficult to extend SaveResult in this way?

Alternatively, is it possible to scope a ListMonitor to a transaction somehow?

Thanks.

Originally created by @jamesbebbington on GitHub (Feb 4, 2016). Is there a way of compiling a changeset of CRUD operations that occurred within a given `transaction`? I see that `commit()` returns a `SaveResult` but that doesn't look to say much about the operations that occurred. Would it be difficult to extend `SaveResult` in this way? Alternatively, is it possible to scope a ListMonitor to a transaction somehow? Thanks.

adam added the enhancement fixed labels 2025-12-29 15:22:46 +01:00

adam closed this issue

2025-12-29 15:22:47 +01:00

adam commented

2025-12-29 15:22:48 +01:00

@JohnEstropia commented on GitHub (Feb 5, 2016):

@fractious Yup, I understand the need. I'm trying to implement automatic CoreSpotlight indexing and bookkeeping changesets is one of the requirements to make it work. Once I get it working I may expose the CRUD changes somewhere.

There's no working prototype yet but you can glimpse of the progress in the _corespotlight-test branch. In the NSManagedObjectContext+CoreSpotlight.swift file, I intend to twiddle with the
insertedObjects:, updatedObjects, and deletedObjects info from the context.

Alternatively, is it possible to scope a ListMonitor to a transaction somehow?

It doesn't make sense with async and sync transactions (their context dies with the closure they run in), but we can allow UnsafeDataTransaction to create their own ListMonitors/ObjectMonitors. I'm not sure if it will help your requirements right now but it seems simple and sensible enough to implement.

@JohnEstropia commented on GitHub (Feb 5, 2016): @fractious Yup, I understand the need. I'm trying to implement automatic CoreSpotlight indexing and bookkeeping changesets is one of the requirements to make it work. Once I get it working I may expose the CRUD changes somewhere. There's no working prototype yet but you can glimpse of the progress in the `_corespotlight-test` branch. In the `NSManagedObjectContext+CoreSpotlight.swift` file, I intend to twiddle with the `insertedObjects:`, `updatedObjects`, and `deletedObjects` info from the context. > Alternatively, is it possible to scope a ListMonitor to a transaction somehow? It doesn't make sense with async and sync transactions (their context dies with the closure they run in), but we can allow `UnsafeDataTransaction` to create their own ListMonitors/ObjectMonitors. I'm not sure if it will help your requirements right now but it seems simple and sensible enough to implement.

adam commented

2025-12-29 15:22:48 +01:00

@jamesbebbington commented on GitHub (Feb 8, 2016):

Yeah that sounds very helpful, I look forward to it.

@jamesbebbington commented on GitHub (Feb 8, 2016): Yeah that sounds very helpful, I look forward to it.

adam commented

2025-12-29 15:22:49 +01:00

@JohnEstropia commented on GitHub (Feb 16, 2016):

Check out the utilities I added here: def105e73a

If there's anything else feel free to ask anytime!

@JohnEstropia commented on GitHub (Feb 16, 2016): Check out the utilities I added here: https://github.com/JohnEstropia/CoreStore/commit/def105e73a09f47e6a7855c392970c92c50778e8 If there's anything else feel free to ask anytime!

adam commented

2025-12-29 15:22:49 +01:00

@jamesbebbington commented on GitHub (Feb 16, 2016):

Sweet, they look good - are they methods on the transaction object?

@jamesbebbington commented on GitHub (Feb 16, 2016): Sweet, they look good - are they methods on the `transaction` object?

adam commented

2025-12-29 15:22:50 +01:00

@JohnEstropia commented on GitHub (Feb 16, 2016):

Yes, so you will need to get the object references before you call commit(). Transaction fetching rules apply, so if you need to access those objects you'll need to use fetchExisting():

CoreStore.beginAsynchronous { transaction in
    // ...
    let insertedObjects = transaction.insertedObjects(YourEntity) // Set<YourEntity>
    transaction.commit { result in
        if result {
            let insertedObjects = CoreStore.fetchExisting(insertedObjects) // [YourEntity]
            // ...
        }
    }
}

@JohnEstropia commented on GitHub (Feb 16, 2016): Yes, so you will need to get the object references before you call `commit()`. Transaction fetching rules apply, so if you need to access those objects you'll need to use `fetchExisting()`: ``` swift CoreStore.beginAsynchronous { transaction in // ... let insertedObjects = transaction.insertedObjects(YourEntity) // Set<YourEntity> transaction.commit { result in if result { let insertedObjects = CoreStore.fetchExisting(insertedObjects) // [YourEntity] // ... } } } ```

adam commented

2025-12-29 15:22:50 +01:00

@jamesbebbington commented on GitHub (Feb 16, 2016):

Cheers John, I'll give it a try on the next release. Thanks!

@jamesbebbington commented on GitHub (Feb 16, 2016): Cheers John, I'll give it a try on the next release. Thanks!

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