-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added search endpoint using rudimentary search algorithm to calculate results based on a simple weighted score system. #412
base: dev
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems odd parameter to have for a search. You want the best result at the top?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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