Improvements to search

[leovegoda]

Is your feature request related to a problem? Please describe. 20C has identified a bundle of issues that should be addressed to improve search experience.

Who is affected by the problem? All PeeringDB users

What is the impact? Addressing these issues will improve search output

Are there security concerns? No

Are there privacy concerns? No

Describe the solution you'd like

1. Issues with parsing search syntax, specifically when it comes to operators driving location searches. a. {object type} in in is currently not turned into a location search b. {object type} in ie is showing uk + ireland

2. near and in should do the same thing a. We don’t see a reason for these to behave differently, both should do a radius search based on the location passed.

3. Search matching defaults to AND when it should be OR a. This should lead to general improvement of results and it being AND by defaultwas likely an oversight / regression introduced without intent.

4. Scoring is currently a mish mash of mostly uncontrolled ES scoring + python on top. Ideally scoring is entirely handled by Elastic Search. a. Difficulty here is that Peeringdb users expect exact matches towards the top, while then maintaining an alphabetic sort for other matches beneath, doing this entirely in Elastic Search is likely problematic.

5. Original implementation started as a proof of concept and had a lot of organic growth since then, cleanup should be done to all code relating to the v2 search. It should also be separated out to individual files for easier maintenance.

6. Presentation of search results a. Separate exact / high score matches into their own section at the top, with lesser matches separated to a section below?

Do you think this feature will require a formal design? Yes

Describe alternatives you've considered Do nothing

Could this feature request need support from the Admin Committee? No

What is the proposed priority? High

Provide a rationale for any/all of the above All our users benefit from offering the best possible search features

[arnoldnipper]

+1

[martinhannigan]

What search code are we using?

On Mon, Apr 15, 2024 at 17:12 Leo Vegoda @.***> wrote:

Is your feature request related to a problem? Please describe. 20C has identified a bundle of issues that should be addressed to improve search experience.

Who is affected by the problem? All PeeringDB users

What is the impact? Addressing these issues will improve search output

Are there security concerns? No

Are there privacy concerns? No

Describe the solution you'd like

1.

Issues with parsing search syntax, specifically when it comes to operators driving location searches. a. {object type} in in is currently not turned into a location search b. {object type} in ie is showing uk + ireland 2.

near and in should do the same thing a. We don’t see a reason for these to behave differently, both should do a radius search based on the location passed. 3.

Search matching defaults to AND when it should be OR a. This should lead to general improvement of results and it being AND by defaultwas likely an oversight / regression introduced without intent. 4.

Scoring is currently a mish mash of mostly uncontrolled ES scoring + python on top. Ideally scoring is entirely handled by Elastic Search. a. Difficulty here is that Peeringdb users expect exact matches towards the top, while then maintaining an alphabetic sort for other matches beneath, doing this entirely in Elastic Search is likely problematic. 5.

Original implementation started as a proof of concept and had a lot of organic growth since then, cleanup should be done to all code relating to the v2 search. It should also be separated out to individual files for easier maintenance. 6.

Presentation of search results a. Separate exact / high score matches into their own section at the top, with lesser matches separated to a section below?

Do you think this feature will require a formal design? Yes

Describe alternatives you've considered Do nothing

Could this feature request need support from the Admin Committee? No

What is the proposed priority? High

Provide a rationale for any/all of the above All our users benefit from offering the best possible search features

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1596, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQUFJYQCBF3S7M6T43LY5Q7EZAVCNFSM6AAAAABGIC33ROVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2DINRSHE2TEOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[martinhannigan]

@grizz what do we use to power the search engine functionality?

tks!

On Mon, Apr 15, 2024 at 20:30 Martin Hannigan @.***> wrote:

What search code are we using?

On Mon, Apr 15, 2024 at 17:12 Leo Vegoda @.***> wrote:

Is your feature request related to a problem? Please describe. 20C has identified a bundle of issues that should be addressed to improve search experience.

Who is affected by the problem? All PeeringDB users

What is the impact? Addressing these issues will improve search output

Are there security concerns? No

Are there privacy concerns? No

Describe the solution you'd like

1.

Issues with parsing search syntax, specifically when it comes to operators driving location searches. a. {object type} in in is currently not turned into a location search b. {object type} in ie is showing uk + ireland 2.

near and in should do the same thing a. We don’t see a reason for these to behave differently, both should do a radius search based on the location passed. 3.

Search matching defaults to AND when it should be OR a. This should lead to general improvement of results and it being AND by defaultwas likely an oversight / regression introduced without intent. 4.

Scoring is currently a mish mash of mostly uncontrolled ES scoring + python on top. Ideally scoring is entirely handled by Elastic Search. a. Difficulty here is that Peeringdb users expect exact matches towards the top, while then maintaining an alphabetic sort for other matches beneath, doing this entirely in Elastic Search is likely problematic. 5.

Original implementation started as a proof of concept and had a lot of organic growth since then, cleanup should be done to all code relating to the v2 search. It should also be separated out to individual files for easier maintenance. 6.

Presentation of search results a. Separate exact / high score matches into their own section at the top, with lesser matches separated to a section below?

Do you think this feature will require a formal design? Yes

Describe alternatives you've considered Do nothing

Could this feature request need support from the Admin Committee? No

What is the proposed priority? High

Provide a rationale for any/all of the above All our users benefit from offering the best possible search features

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1596, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQUFJYQCBF3S7M6T43LY5Q7EZAVCNFSM6AAAAABGIC33ROVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2DINRSHE2TEOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[grizz]

django-haystack and ElasticSearch

[jackcarrozzo]

+1

[mcmanuss8]

+1

[jbartig]

+1

[martinhannigan]

+1

On Thu, May 2, 2024 at 12:26 PM Jeff Bartig @.***> wrote:

+1

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1596#issuecomment-2090965787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQQ2JABFS6WUARMU2MDZAJSLBAVCNFSM6AAAAABGIC33ROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJQHE3DKNZYG4 . You are receiving this because you commented.Message ID: @.***>