Added search endpoint using rudimentary search algorithm to calculate results based on a simple weighted score system. #412
Conversation
…culate results based on a simple weighted score system.
| @@ -100,4 +100,18 @@ export default class GlobalCharacterAggregateEntity { | |||
| default: Ps2AlertsEventType.LIVE_METAGAME, | |||
| }) | |||
| ps2AlertsEventType: Ps2AlertsEventType; | |||
|
|
|||
| @Exclude() | |||
There was a problem hiding this comment.
Prevents this being persisted to the entity but allows us to add it to objects in results
|
Why scores? Why not just search based on lower case with a partial result using starts with? |
|
Alternatively https://www.mongodb.com/docs/manual/text-search/ |
Tried that, text indexes only work with whole words, we need the use of partials. |
I want exact matches to be higher in the list, e.g. if someone searches DIG it'll return the outfit by tag at the highest, then by outfit name, then by character name starting with that search term. Check the code it should make more sense. |
|
@microwavekonijn responded |
|
Ah right, yeah. Okay I get it now. Though maybe just pushing exact matches to the front makes more sense as it is more efficient. I don't think this is the right approach though in general. If you search for a character you should just search by name. Outfits same story though name and tag. However searching character by outfit name or tag seems a bit convoluted to me. A more straight forward approach is use the outfit search to get the outfit id, which then allows the character search to be narrowed to just that outfit in a separate character query. |
| }) | ||
| async search( | ||
| @Query('searchTerm') searchTerm: string, | ||
| @Query('type') @Optional() type?: string, |
There was a problem hiding this comment.
I would probably split this endpoint into two, one for characters and one for outfits. I also would use an actual enum as the type.
Also you might want to look at the NestJS Swagger CLI plugin.
| let characterResults: GlobalCharacterAggregateEntity[] = []; | ||
| let outfitResults: GlobalOutfitAggregateEntity[] = []; | ||
|
|
||
| const pagination = new Pagination({sortBy, order, page: 0, pageSize: 10}, false); |
There was a problem hiding this comment.
I think this conflicts with your search algorithm, as the subset might ignore better results.
| @Query('sortBy') sortBy?: string, | ||
| @Query('order') order?: string, |
There was a problem hiding this comment.
This seems odd parameter to have for a search. You want the best result at the top?
There was a problem hiding this comment.
Good spot, oversight
Yeah I'm gonna refactor this slightly in the following way:
Primarily this maintains the KISS and single responsibility principle rather than trying to do too much in the endpoint itself. A secondary benefit, while small, it will reduce the load on the server having to do the sorting whereas clients can do it much quicker. |
…earch index in Redis and updates it periodically with new players and outfits
… in order to get victory stats. Made common instance retrieval service to handle caching of instances to make the findMany operation very quick
…and caching policy
Closes #317
Related: ps2alerts/website#489