Tables for labels and categories?

[vrom911]

No description provided.

[rashadg1030]

@vrom911 Yes good question. Originally we did have a table for labels and categories, but I think we decided we didn't need it and it complicated the database schema, so we removed it...I forgot the exact reason why. If you look at the code from earlier in the project you can see it. Should we add this back into the code?

[rashadg1030]

@chshersh @vrom911 Bump

[chshersh]

@rashadg1030 This issue is about creating separate tables for labels and categories for caching purposes. Previously we were using those tables as the only place to store this information. But now we still have columns with type array in the main table. The point of having separate tables is the ability to fetch all unique labels and categories on frontend when the page is loaded. For autocompletion and discovery purposes. If we need to SELECT unique labels and categories each time the page is loaded by scanning big tables of repos and issues our backend might die...

The only difficulty with this issue at the moment is how to populate those tables efficiently.

[rashadg1030]

@chshersh Okay got it makes sense. Thank you for explaining. I'm ready to tackle this issue, but should we figure out how to optimize the syncing algorithm first?

[rashadg1030]

@chshersh @vrom911 So for GitHub labels are we just selecting a few labels that we think are useful or do we plan on fetching all the labels on GitHub? I'm assuming the former. In that case, which labels should we select?

EDIT: Scratch out what I said above. I think what you're implying is that once we sync are issues and repos, we can scan those tables and create the categories and issues tables from that data. If this is correct let me know, because I would like to work on that.

[chshersh]

@rashadg1030 Sure, let's finish with the sync first and think about proper caching. Not sure how it should be done, but probably one more step after syncing.