WIP: Dailylog optimization #18
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The configured parameters is the dailycalls file but CallRegistry takes its parent dir for the rest of the managed files. This commit still receives the dailycalls configuration but computes the parent in the constructor and then just relies on the parent.
Instead of configure a concrete callinfo log file, configure the path. callregistry relies now on that file.
This way call log and annotation log are even more closer and we avoid handling both types of index. Sandwich criteria, pbxsends us extensions, internally we manage just tomatic users.
to be consistent with the semantics of the former commit. Indeed tests used user names as well.
This fixes a rare bug that stores twice the same annotation when opened in two different windows. Also prepares the way to be able to write unannotated calls in the case registry.
vokimon
force-pushed
the
dailylog-optimization
branch
from
7b3c320
to
89ce314
Compare
Having a single entry point from the api The case uploader still could identify unnanotated by checking the reason Field mapping already done inside annotateCall, now centralized and hidden.
There is no need to codify the color in the cookie if we can obtain it from Tomatic object. On load, person info might not available yet, so the conditional keeps ups safe
By centralizing this op, it will be easier to change what it does
whoAreYou was a quite messy name provided that myName and tellMeWhoIAm are spread around with quite different semantics (one gives the user cookie and the other the user id)
vokimon
force-pushed
the
dailylog-optimization
branch
from
89ce314
to
88a5b0f
Compare
Adding a test to ensure we can refactor without losing that functionality test_updateCall_limitedSize_forgetsOlder Indeed it raised the bug that made the call log grow forever. Assigning to a local var does not update the original list.
Rationale: You never have to load calls from different persons. Just separate them and thus ensuring that they only have 20 calls as much to parse. Far from the 1400 for 70 users or the 8800 currently in production (because the previous fixed bug)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Call log tends to grow and makes callinfo to be slow. This PR tries to reorganize the call logging so that it is more lean.
Commits are granular and contain full explanation so that it can be reviewed commit by commit.