Originally created by @jamesbebbington on GitHub (Apr 22, 2016).
Hey John,
I may be being a bit stupid here but, from having read the README it's not clear to me how I should be returning NSManagedObjects from synchronous transactions. I see CoreStore provides fetchExisting but I'm not sure how to use it in this example:
funccreateFoo()->Foo?{guardletresult=CoreStore.beginSynchronous({transactioninletfoo=transaction.create(Into(Foo))foo.createdAt=NSDate()transaction.commitAndWait()})else{returnnil}switchresult{case.Success:return?// How do I return the newly created Foo instancecase.Failure:returnnil}}
Thanks.
Originally created by @jamesbebbington on GitHub (Apr 22, 2016).
Hey John,
I may be being a bit stupid here but, from having read the README it's not clear to me how I should be returning `NSManagedObject`s from synchronous transactions. I see CoreStore provides `fetchExisting` but I'm not sure how to use it in this example:
``` swift
func createFoo() -> Foo? {
guard let result = CoreStore.beginSynchronous({ transaction in
let foo = transaction.create(Into(Foo))
foo.createdAt = NSDate()
transaction.commitAndWait()
}) else { return nil }
switch result {
case .Success:
return ? // How do I return the newly created Foo instance
case .Failure:
return nil
}
}
```
Thanks.
adam
added the question label 2025-12-29 18:21:59 +01:00
The risk of deadlock with synchronous transactions are kind of worrying though. I recommend you use asynchronous transactions instead, or to call beginSynchronous() from a background thread.
Otherwise, if you are just creating a new object and you don't need to fetch from within the transaction, it might actually be safe and performant to not rely on the transaction queueing mechanism.
@JohnEstropia commented on GitHub (Apr 23, 2016):
You'll need to assign it to an outer variable.
``` swift
var foo: Foo? // Foo!
guard let result = CoreStore.beginSynchronous({ transaction in
foo = transaction.create(Into(Foo))
foo?.createdAt = NSDate()
transaction.commitAndWait()
}) else { return nil }
switch result {
case .Success:
return foo.flatMap(CoreStore.fetchExisting) // CoreStore.fetchExisting(foo!)
case .Failure:
return nil
}
```
The risk of deadlock with synchronous transactions are kind of worrying though. I recommend you use asynchronous transactions instead, or to call `beginSynchronous()` from a background thread.
Otherwise, if you are just creating a new object and you don't need to fetch from within the transaction, it might actually be safe and performant to not rely on the transaction queueing mechanism.
``` swift
let transaction = CoreStore.beginUnsafe()
let foo = transaction.create(Into(Foo))
foo.createdAt = NSDate()
transaction.commitAndWait()
return CoreStore.fetchExisting(foo)
```
@jamesbebbington commented on GitHub (Apr 25, 2016):
Thanks John, that's what I was looking for. And thanks for the warning about deadlocks, I'll try and migrate over to asynchronous transactions.
@jamesbebbington commented on GitHub (Apr 25, 2016):
Thanks John, that's what I was looking for. And thanks for the warning about deadlocks, I'll try and migrate over to asynchronous transactions.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @jamesbebbington on GitHub (Apr 22, 2016).
Hey John,
I may be being a bit stupid here but, from having read the README it's not clear to me how I should be returning
NSManagedObjects from synchronous transactions. I see CoreStore providesfetchExistingbut I'm not sure how to use it in this example:Thanks.
@JohnEstropia commented on GitHub (Apr 23, 2016):
You'll need to assign it to an outer variable.
The risk of deadlock with synchronous transactions are kind of worrying though. I recommend you use asynchronous transactions instead, or to call
beginSynchronous()from a background thread.Otherwise, if you are just creating a new object and you don't need to fetch from within the transaction, it might actually be safe and performant to not rely on the transaction queueing mechanism.
@jamesbebbington commented on GitHub (Apr 25, 2016):
Thanks John, that's what I was looking for. And thanks for the warning about deadlocks, I'll try and migrate over to asynchronous transactions.