Split search API into channels and claims ?

tzarebczan commented

2018-08-27 20:04:59 +02:00

(Migrated from github.com)

The way search works right now, it will return the top X claims and channels based on a search query. This could lead to issues finding channels if the claim results "overwhelm" the channel ones. One example is searching for Lunduke. Since he has Lunduke in title names, you only get a bunch of claim results, and nothing on the Channel side. If I increase the search result #s, I eventually get the channel (tried it at 300).

The way search works right now, it will return the top X claims and channels based on a search query. This could lead to issues finding channels if the claim results "overwhelm" the channel ones. One example is searching for `Lunduke`. Since he has Lunduke in title names, you only get a bunch of claim results, and nothing on the Channel side. If I increase the search result #s, I eventually get the channel (tried it at 300).

👍 1

tiger5226 commented

2018-09-16 04:19:25 +02:00

(Migrated from github.com)

@seanyesmunt How will the app handle this? would you prefer two sets of x results, or 1 set of 2x results split equally between claims and channels.

neb-b commented

2018-09-17 15:36:40 +02:00

(Migrated from github.com)

I think one set of 2x results split equally (or at least make sure there is no less than 1 channel if one exists or something) would work best.

kauffj commented

2018-09-17 16:01:57 +02:00

(Migrated from github.com)

Rather than modifying the signature and behavior of generic search (/search?s=<term>), maybe these should just be distinct calls?

If the app wants to display n file results and n channel results, it may make sense to just make two distinct calls with different parameters/signatures.

Rather than modifying the signature and behavior of generic search `(/search?s=<term>`), maybe these should just be distinct calls? If the app wants to display `n` file results and `n` channel results, it may make sense to just make two distinct calls with different parameters/signatures.

kauffj commented

2018-09-17 16:03:23 +02:00

(Migrated from github.com)

My comment may still be unclear. Rather than either splitting the response signature of search or replacing search with two new calls, I'm suggesting simply adding two new calls (or a new parameter to search) and leaving search called as-is with the same behavior.

My comment may still be unclear. Rather than either splitting the response signature of `search` or _replacing_ search with two new calls, I'm suggesting simply _adding_ two new calls (or a new parameter to `search`) and leaving `search` called as-is with the same behavior.

tiger5226 commented

2018-09-18 05:26:11 +02:00

(Migrated from github.com)

@kauffj The way the elasticsearch query works is we can x hits from a search. To differentiate between files and channels we would have to do post processing. Right now we just return the to n hits from the results through the api. In this case we would have to iterate over the results and get m files and n channels.

Also another consideration I am thinking of now is that in the future we will have more than two types of claims. So it may be best to just use the claim_type int instead to specify what we want.

I am going to think about this some more.

@kauffj The way the elasticsearch query works is we can x hits from a search. To differentiate between files and channels we would have to do post processing. Right now we just return the to n hits from the results through the api. In this case we would have to iterate over the results and get m files and n channels. Also another consideration I am thinking of now is that in the future we will have more than two types of claims. So it may be best to just use the claim_type int instead to specify what we want. I am going to think about this some more.

kauffj commented

2018-09-18 15:58:36 +02:00

(Migrated from github.com)

I think adding a claim_type=<channel|file> parameter would be a sensible design.

I think adding a `claim_type=<channel|file>` parameter would be a sensible design.

tiger5226 commented

2018-09-19 04:51:04 +02:00

(Migrated from github.com)

Yeah, I agree. 2 calls is best with the claim_type parameter which defaults to all if not passed.

@seanyesmunt Does this make sense to you?

Yeah, I agree. 2 calls is best with the `claim_type` parameter which defaults to all if not passed. @seanyesmunt Does this make sense to you?

neb-b commented

2018-11-26 15:15:03 +01:00

(Migrated from github.com)

@tiger5226 A little late to this, but yes.

👍 1

tiger5226 commented

2019-02-09 23:34:09 +01:00

(Migrated from github.com)

merged and deployed with #144

Split search API into channels and claims ? #109