Originally created by @andreaperizzato on GitHub (Oct 1, 2015).
Hi,
I have two entities related by a one-to-one relationships (let's call them A and B) and a ListObserver observing the list of As. Both entities conform to ImportableUniqueObject and the relationship is set on A as follows:
Then I have an async transaction updating the list of As.
When I commit the transaction, I noticed that only the temporary context is saved, while the parent context is not because its hasChanges is false. This causes the changes not to be merged in the main context has the list observer not to be updated.
Removing the relationships from the model solves the problem.
Originally created by @andreaperizzato on GitHub (Oct 1, 2015).
Hi,
I have two entities related by a one-to-one relationships (let's call them `A` and `B`) and a `ListObserver` observing the list of `A`s. Both entities conform to `ImportableUniqueObject` and the relationship is set on `A` as follows:
``` swift
func updateFromImportSource(source: [String : AnyObject], inTransaction transaction: BaseDataTransaction) throws {
self.name = source["name"] as! String
if let otherSource = source["other"] as? [String : String] {
self.other = try transaction.importUniqueObject(Into(OtherUniqueEntity), source: otherSource)!
}
}
```
Then I have an async transaction updating the list of `A`s.
When I commit the transaction, I noticed that only the temporary context is saved, while the parent context is not because its `hasChanges` is `false`. This causes the changes not to be merged in the main context has the list observer not to be updated.
Removing the relationships from the model solves the problem.
adam
added the wontfix label 2025-12-29 15:22:01 +01:00
@andreaperizzato
Is the inverse relationship properly set for other? If so, I don't see why it wouldn't work (we have similar setups in our own project), so there must be something we're missing.
Are you sure that self.other is being set to a new instance of OtherUniqueEntity? If the previous value of self.other is the same instance returned by transaction.importUniqueObject(), your ListMonitor will not receive an update notification (as you have seen where hasChanges=false).
@JohnEstropia commented on GitHub (Oct 1, 2015):
@andreaperizzato
Is the inverse relationship properly set for `other`? If so, I don't see why it wouldn't work (we have similar setups in our own project), so there must be something we're missing.
Are you sure that `self.other` is being set to a new instance of `OtherUniqueEntity`? If the previous value of `self.other` is the same instance returned by `transaction.importUniqueObject()`, your `ListMonitor` will not receive an update notification (as you have seen where `hasChanges=false`).
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 @andreaperizzato on GitHub (Oct 1, 2015).
Hi,
I have two entities related by a one-to-one relationships (let's call them
AandB) and aListObserverobserving the list ofAs. Both entities conform toImportableUniqueObjectand the relationship is set onAas follows:Then I have an async transaction updating the list of
As.When I commit the transaction, I noticed that only the temporary context is saved, while the parent context is not because its
hasChangesisfalse. This causes the changes not to be merged in the main context has the list observer not to be updated.Removing the relationships from the model solves the problem.
@JohnEstropia commented on GitHub (Oct 1, 2015):
@andreaperizzato
Is the inverse relationship properly set for
other? If so, I don't see why it wouldn't work (we have similar setups in our own project), so there must be something we're missing.Are you sure that
self.otheris being set to a new instance ofOtherUniqueEntity? If the previous value ofself.otheris the same instance returned bytransaction.importUniqueObject(), yourListMonitorwill not receive an update notification (as you have seen wherehasChanges=false).@JohnEstropia commented on GitHub (Oct 3, 2015):
@andreaperizzato Did you resolve this problem?