Skip to content
This repository has been archived by the owner. It is now read-only.

Split eventtags table into sub-tables #95

Merged
merged 2 commits into from Aug 3, 2017

Conversation

Projects
None yet
2 participants
@c-w
Copy link
Member

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 Aug 2, 2017

@c-w c-w added the in progress label Aug 2, 2017

@erikschlegel

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2017

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

@erikschlegel
Copy link
Contributor

left a comment

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

@c-w

This comment has been minimized.

Copy link
Member Author

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

Remove mentionedtopics table
See rationale in comment
#95 (comment)

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 force-pushed the eventtags-table-update branch from dfabc73 to abdb81e Aug 3, 2017

@c-w c-w merged commit 759c8af into master Aug 3, 2017

0 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@c-w c-w deleted the eventtags-table-update branch Aug 3, 2017

@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.
You can’t perform that action at this time.