Skip to content
This repository has been archived by the owner on Mar 7, 2018. It is now read-only.

Split eventtags table into sub-tables #95

Merged
merged 2 commits into from
Aug 3, 2017
Merged

Conversation

c-w
Copy link
Contributor

@c-w c-w commented Aug 2, 2017

See usage example in 63fd942.

The eventtopics table is used in the MessagesSchema.byEdges query where we need to find all the events for a particular set of keywords. This is why we index the table on the topics and link the eventids.

The mentionedtopics table is used in the EdgesSchema.terms query to find all the keywords for a particular time period. We can't re-use the eventtopics table since we don't have access to a topic here.

The eventplaces table is used in the MessagesSchema.byBbox query to find all the events for a particular keyword combination, timespan and bounding box. Potentially this table can be further simplified to index off of tile-{x,y,z} instead of placeid if we pass through the zoom-level from the frontend. This would allow us to get rid of the query to the featureService.

@c-w c-w requested a review from erikschlegel August 2, 2017 17:29
@c-w c-w added the in progress label Aug 2, 2017
@erikschlegel
Copy link
Contributor

That's a brilliant idea. Nice work. LGTM.

Copy link
Contributor

@erikschlegel erikschlegel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I noticed that location isnt associated to mentionedtopics and eventtopics?

@c-w
Copy link
Contributor Author

c-w commented Aug 3, 2017

@erikschlegel Yes, that's true. The new tables are pretty specific.

The mentionedtopics table is there to enable queries such as "give me all the keywords for which we have events in the last 30 days" which is used in the facts view of the Fortis dashboard for the dropdown keyword filter. We could get rid of this table at a very slight UX hit and simply display all topics in the dropdown instead of all the topics for which we have at least one event.

The eventtopics table is there for queries like "give me all the events that match one of these keywords" so we don't need a notion of places in this context. This query is used in the activity feed and in the facts list components. Should we get rid of the endpoint in favor of the one that queries by keywords and by bounding box and pass the current bounding box from the frontend?

Thoughts?

c-w added a commit that referenced this pull request Aug 3, 2017
c-w added a commit to CatalystCode/project-fortis-services that referenced this pull request Aug 3, 2017
@c-w c-w changed the title Split eventtags table into three sub-tables Split eventtags table into sub-tables Aug 3, 2017
@c-w c-w merged commit 759c8af into master Aug 3, 2017
@c-w c-w deleted the eventtags-table-update branch August 3, 2017 23:00
@c-w c-w removed the in progress label Aug 3, 2017
rachelnicole pushed a commit that referenced this pull request Jan 24, 2018
rachelnicole pushed a commit that referenced this pull request Jan 24, 2018
rachelnicole pushed a commit that referenced this pull request Jan 24, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants