This repository was archived by the owner on Mar 7, 2018. It is now read-only.
Remove usage of MessagesSchema byLocations endpoint#10
Merged
Conversation
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); |
Contributor
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?
Contributor
Author
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
erikschlegel
left a comment
erikschlegel
left a comment
Collaborator
There was a problem hiding this comment.
LGTM with one minor question below.
|
|
||
| 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) { |
Collaborator
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.
Contributor
Author
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.
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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