-
Notifications
You must be signed in to change notification settings - Fork 0
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
Subject index #608
Subject index #608
Conversation
196db33
to
49a1c06
Compare
search-api/src/main/scala/no/ndla/searchapi/controller/parameters/SearchParamsDTO.scala
Outdated
Show resolved
Hide resolved
search-api/src/main/scala/no/ndla/searchapi/model/search/SearchableNode.scala
Show resolved
Hide resolved
search-api/src/main/scala/no/ndla/searchapi/service/search/NodeIndexService.scala
Show resolved
Hide resolved
search-api/src/main/scala/no/ndla/searchapi/service/search/NodeIndexService.scala
Show resolved
Hide resolved
92f56b9
to
9f6724d
Compare
with subjectdata
To more easily allow typescript to guard for these.
9f6724d
to
fbe1a6b
Compare
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.
Dersom målet på sikt er å kunne søke på alle noder, bør du sikkert også ha med contexts for å støtte alle plasseringer en node kan ha i struktur. Dersom kun fag skal vises, er det du har nok.
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.
Usikker på om det er problematisk, men for alle andre søkeresultat så peiker url på api-url, men det returneres liste med context som har url som er korrekt frontendurl. Burde kanskje gjort det likt her.
Er det meininga at det skal være NodeHitDTO?
|
Har du frontpage-api kjørende med data? |
Bedre!:
|
Er denne egentlig klar for review? |
Jeg kom på at jeg hadde lagt igjen en todo på suggestions, så jeg burde sikkert se mer på det før vi prøver å merge den. |
Since we are already over the limit if we don't use dynamic mapping, this is the first attempt at removing some unused language fields.
We can just use the `domainObject` mapping for this instead since we are not searching the field.
a07397a
to
00aa1a9
Compare
This is to limit the sizes of the indexes.
00aa1a9
to
f7ec255
Compare
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
Even though the problems with dynamic mappings are most prevalent in search-api. I see no reason to keep using it in all places when search-api does not.
af62f82
to
920d9ee
Compare
Tror denne er klar for review nå. Sluttet å bruke dynamisk mapping rundtomkring med grunnlag i at vi mister litt kontroll på hva som kan søkes på og ikke; da det fort er basert på dataen som er indeksert. Feks problemet som oppstod her var at vi ikke kunne bruke suggestions på multi-index søket i search-api når vi fikk inn node indexen siden suggestionen gjør at hele søket på node sharden feiler siden feltet "content.nb" ikke fantes. Ser for meg at det er lett å skyte seg selv i foten med senere dersom vi bruker et sjeldent språk i en av index'ene for eksempel. Siden vi fjerner dynamisk mapping så får vi litt begrensninger på hvor mange språk vi kan støtte samtidig med denne modellen, så la inn et konfigurasjonsflagg for å bestemme hvilke fag som støttes. Vurderte å endre modellen til å bruke nested dokumenter for språkfelter å fremdeles kunne støtte alle språkene samtidig, men følte det kanskje var et unødvendig ytelse-hit om vi kan leve med å støtte litt færre språk samtidig. Syns den løsningen hadde vært "cleanere" kodemessig, men mtp usikker ytelse så blir nok dette "tryggest" 🤓 |
@@ -58,6 +58,15 @@ trait BaseProps { | |||
def TaxonomyUrl: String = s"http://$TaxonomyApiHost" | |||
def disableWarmup: Boolean = booleanPropOrElse("DISABLE_WARMUP", default = false) | |||
|
|||
def SupportedLanguages: List[String] = | |||
propOrElse("SUPPORTED_LANGUAGES", "nb,nn,en,sma,se,de,es,zh,ukr").split(",").toList |
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.
Disse er de som finnes i ed
pr nå, men tar i mot forslag på hvilke vi trenger.
Jo færre jo bedre egentlig da 🤓
Kan merge denne no regner eg med. |
Add indexing of subjects