Split eventtags table into sub-tables

[c-w]

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.

[erikschlegel]

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

[erikschlegel]

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

[c-w]

@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?