-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixes and improvements related to Core Data usage #1443 #1471
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes all look good! I did a smoke test and didn't see any problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! It seems you caught a ton of potential issues here! I'm ok with all of these changes. I just left two minor comments. The PR looks fine even if you don't address them but I'd like to see your opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love this! I agree with Martin about multiline if
clauses and would prefer to see that changed, but these are big improvements and this is 100% shippable from my perspective.
# Conflicts: # CHANGELOG.md # Nos/Models/CoreData/Event+CoreDataClass.swift
@martindsq I think in this case posting your review as a Comment rather than Request Changes would have sped things along. Right now merging is blocked waiting on your approval even though you said you were fine with all changes. I know we have had some debate about when to use Request Changes vs Comment so I wanted to point this out. If we had folks who just clicked merge and forgot to come back and finish the "optional" conversations then I don't think Comment would be a good idea. But I think we have a team who stays on top of their Github conversations which is great, so I think we can trust that in general. |
Issues covered
#1443
Description
These changes are the result of the Core Data usage research prescribed by #1443. They are the changes I was confident making without further discussion. Other suggestions will be mentioned in the ticket.
This code:
Event().createIfNecessary(jsonEvent...
is creating Events and throwing them away immediately and causing the console error message "Failed to call designated initializer on NSManagedObject". The resolution is to make thecreateIfNecessary...
function static.Adding the launch argument
-com.apple.CoreData.ConcurrencyDebug 1
reveals thatEvent.loadFirstQuotedNote()
is creating an event on the wrong thread. The resolution is to move theEvent.findOrCreateStubBy...
call to inside thecontext.perform
call below. Reference https://useyourloaf.com/blog/debugging-core-data/.In
RelayService.retryFailedPublishes()
, a JSONEvent was being created inside a nested loop. This caused needless extra work because it could be created only in the outer loop.How to test
These changes aren't user testable, but they are dev testable.
Running
main
(prior to the changes in this PR), you will see a message in the console like this:"Failed to call designated initializer on NSManagedObject"
If you add the launch argument
-com.apple.CoreData.ConcurrencyDebug 1
to the scheme and run the code, you will get a crash (an assert really) if you scroll around in a feed view that contains quoted notes.After the changes in this PR, both of those issues are resolved.