Use query for token completion

[rastersize]

We should use a query for token completion instead of just loading all possible forms of tokens into memory at init (i.e. this is the branch which will help alleviate the crazy long startup time).

:notebook_with_decorative_cover: You must run pod update to use this branch as it includes pods not in the master branch.

To do

• [x] Update code to reflect -getRelatedTagsForTagWithName: now returning an array of OPFTag objects.
• [x] Add a proper query for finding users matching entered text.
• [x] Add a proper query for finding users when no token text has been entered text.
• [x] Update the tag suggestion to decrease the amount of shown tags as more tags are entered.
• [ ] Change so token being inputted isn’t being used as a keyword but rather a tag. Will fix on master instead as this branch is holding up @gothma’s work.
• [x] Fix the database race condition.

[jesjos]

I'm looking into the task. Give me a heads up if you're doing it too, so we can avoid duplicate work.

[rastersize]

We are currently suggesting tags which will result in zero results. For example by first selecting “java” and then “multithreading” suggestions such as “jsp” will be made, unfortunately there are no questions tagged with all three tags. In my tired state of mind I’m thinking a query which selects all posts by the inputted tag IDs and then returns all tags associated with those. (Not sure how to actually do that in SQL if possible at all? Join from hell :no_good:?)

Our current behavior of constructing a union of all tags related to each tag already inputted also results in the amount of tags growing each time the user decides to refine her search. Thus the suggestions bar has the opposite effect.

[jesjos]

Yeah, it's really a problem and it's mostly due to the fact that we only track frequencies for tag pairs. We can't say anything meaningful about groups of more than two tags. Doing the post selection thing would be very inefficient. Granted, we could easily get all tags with at least a given set of tags, but as far as I know counting them in one SQL query would be nearly impossible - meaning that we would have to get a potentially huge amount of data from the db and process it in the front end. Or a large amount of SQL per search string frankly don't know how to solve this best.

Den söndagen den 5:e maj 2013 skrev Aron Cedercrantz:

We are currently suggesting tags which will result in zero results. For example by first selecting “java” and then “multithreading” suggestions such as “jsp” will be made, unfortunately there are no questions tagged with all three tags. In my tired state of mind I’m thinking a query which selects all posts by the inputted tag IDs and then returns all tags associated with those. (Not sure how to actually do that in SQL if possible at all? Join from hell [image: :no_good:]?)

Our current behavior of constructing a union of all tags related to each tag already inputted also results in the amount of tags growing each time the user decides to refine her search. Thus the suggestions bar has the opposite effect.

— Reply to this email directly or view it on GitHubhttps://github.com/opfo/app/pull/32#issuecomment-17443598 .

[rastersize]

As per todays discussion, we will instead just show less tags :smile_cat:

[rastersize]

:notebook_with_decorative_cover: You must run pod update to use this branch as it includes pods not in the master branch.

[jesjos]

You're also required to do update_dbs force