This repository has been archived by the owner on Mar 7, 2018. It is now read-only.
Remove usage of MessagesSchema byLocations endpoint #10
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
In Fortis-V1, when the user selects the filter terms, we have a distinction between keywords (like "Isis" or "Bomb") and locations (like "Syria" or "Benghazi"): if we query for all events that contain a keyword, we'll match the keyword in the text, if we query for all events that contain a location, we instead match for the location's coordinates in the event's metadata. In Fortis-V2, we no longer support this distinction as it's much easier to just treat keywords and locations the same by just using the locations' name as an additional keyword for which to query. As a result, we need to remove the usage of the MessagesSchema byLocations endpoint in the GraphGL client. Note that the change of deprecating this endpoint has already been made on the GraphQL service, in the branch: https://github.com/CatalystCode/project-fortis-services/tree/implement-tiles-resolver
c-w
changed the title
c-w
added a commit
that referenced
this pull request
Jul 28, 2017
This is a sister-change to pull request #10, see the the description of that change for further information.
Smarker
approved these changes
Aug 7, 2017
|
|
||
| SERVICES.FetchMessageSentences(siteKey, originalSource, bbox, datetimeSelection, timespanType, | ||
| limit, offset, edges, DEFAULT_LANGUAGE, Actions.DataSources(filteredSource), | ||
| categoryValue?categoryValue.name.toLowerCase():categoryValue, searchValue, location, callback); | ||
| categoryValue?categoryValue.name.toLowerCase():categoryValue, searchValue, undefined, callback); |
There was a problem hiding this comment.
I'm hesitant to pass in undefined as a parameter, since this might introduce new errors. Would there be a way to change the signature of this so it doesn't take a location parameter?
There was a problem hiding this comment.
I usually like keeping changes minimal to keep risk low, but sure. Done in 0f94c6b.
erikschlegel
approved these changes
Aug 9, 2017
| @@ -704,23 +704,13 @@ export const SERVICES = { | |||
|
|
|||
| let query, variables; | |||
|
|
|||
| if (coordinates && coordinates.length === 2) { | |||
| query = ` ${fragmentView} | |||
| query ByLocation($site: String!, $originalSource: String, $coordinates: [Float]!, $filteredEdges: [String]!, $langCode: String!, $limit: Int!, $offset: Int!, $fromDate: String!, $toDate: String!, $sourceFilter: [String], $fulltextTerm: String) { | |||
There was a problem hiding this comment.
why are we getting rid of ByLocation? This is used when you select a place from the popular locations donut chart.
There was a problem hiding this comment.
Let me merge this and then I'll have to revert this and #11 which already got merged.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
In Fortis-V1, when the user selects the filter terms, we have a distinction between keywords (like "Isis" or "Bomb") and locations (like "Syria" or "Benghazi"): if we query for all events that contain a keyword, we'll match the keyword in the text, if we query for all events that contain a location, we instead match for the location's coordinates in the event's metadata.
In Fortis-V2, we no longer support this distinction as it's much easier to just treat keywords and locations the same by just using the locations' name as an additional keyword for which to query.
As a result, we need to remove the usage of the MessagesSchema byLocations endpoint in the GraphGL client. Note that the change of deprecating this endpoint has already been made on the GraphQL service, in the branch https://github.com/CatalystCode/project-fortis-services/tree/implement-tiles-resolver