-
Notifications
You must be signed in to change notification settings - Fork 5
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
Qf logging #654
Qf logging #654
Conversation
Move question finder search logging from the app to the API.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #654 +/- ##
==========================================
+ Coverage 34.17% 34.44% +0.26%
==========================================
Files 520 521 +1
Lines 23255 23417 +162
Branches 2850 2869 +19
==========================================
+ Hits 7947 8065 +118
- Misses 14507 14540 +33
- Partials 801 812 +11 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
@@ -364,6 +364,26 @@ public final Response getQuestionList(@Context final Request request, | |||
limit = idsList.size(); | |||
} | |||
|
|||
int finalStartIndex = startIndex; |
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.
What is this for? Why not just use startIndex
below?
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.
Using startIndex
causes an error ("Variable 'startIndex' is accessed from within inner class, needs to be final or effectively final").
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.
Oh, I see.
Why not just make a hashmap and add things to it, rather than double-brace initialise it? That would save on making a new class every request, too!
Co-authored-by: James Sharkey <[email protected]>
Co-authored-by: James Sharkey <[email protected]>
The frontend QUESTION_FINDER_SEARCH values were in a different format, which is easier to query inside Postgres. Except QUESTION_STATUSES, which were stored as a map to boolean values, but this is terrible to query, so move instead to a list of provided statuses.
Move question finder search logging from the app to the API.