Closed mortenmo closed 6 months ago
Closes: #123
in the PR description, so I can recognize it.Looks good! I think you may have fixed a circular dependency as well.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.00%. Comparing base (
72bc9ac
) to head (7bd2a22
). Report is 13 commits behind head on alpha.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@mtrezza This is ready for review. I'm not sure why the CI isn't running
Does the PR title make sense?
Yeah I believe so
🎉 This change has been released in version 5.1.0-alpha.6
🎉 This change has been released in version 5.1.0-beta.1
🎉 This change has been released in version 5.1.0
EventuallyQueue behavior isn't always what I need. Was hoping to have a way to replace the default to change the behavior. Using CoreManager felt like the obvious way.
Issue
EventuallyQueue gives you no control over what happens if there are conflicts. For example, another client has changed the object, it just looks at updatedAt time and drops the local changes. Fine as a general rule, but sometimes I need some control over that in an often offline environment.
Approach
There were only 3 places that called EventuallyQueue directly. Just changed those to use
CoreManager.getEventuallyQueue()
following the patterns of most other things going through CoreManager.Tasks