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
Merged

Split eventtags table into sub-tables #95

merged 2 commits into from Aug 3, 2017

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 Aug 2, 2017
@c-w c-w added the in progress label Aug 2, 2017
@erikschlegel
Copy link
Contributor

@erikschlegel erikschlegel commented Aug 3, 2017

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

Copy link
Contributor

@erikschlegel erikschlegel left a comment

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

@c-w
Copy link
Contributor Author

@c-w 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 issue Aug 3, 2017
See rationale in comment
#95 (comment)
c-w added a commit to CatalystCode/project-fortis-services that referenced this issue 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
@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 issue Jan 24, 2018
rachelnicole pushed a commit that referenced this issue Jan 24, 2018
rachelnicole pushed a commit that referenced this issue 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
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants