"The Solr Way" (tm) would be to flatten the data and store multiple
records, i.e.
id key lang lang_display
1_EN 1ENindia
1_TAM 1TAM \u0b87\u0ba8\u0bcd\u0ba4\u0bbf\u0baf\u0bbe
where lang was indexed but possibly not stored and lang_dislplay was
stored but possibly not indexed (or docValues or)
This can bloat the index if carried too far, since the number of
records becomes the cross product of all the different possibilities.
That said, until you get into the multiple 10s of millions it's
usually not a problem.
[subquery] is going to be somewhat expensive. You're right it'll only
execute on the docs returned, so if rows=10 the subqueries will be
performed only for those 10 docs. But that's 10 *
number_of_subquery_fields so could explode a bit.
Note I had to play a bit with the "id" field since it's akin to a
primary key in a database so must be different for each record you
want to have available.
Or, if you wanted to keep the record as your example, you might just
store {"EN":"India","TAM":"\u0b87\u0ba8\u0bcd\u0ba4\u0bbf\u0baf\u0bbe"}
in, say, a "languages" string field and have the front-end pull out
the right part based on the language desired using your favorite JSON
parser or whatever.
Best,
Erick
On Sat, May 19, 2018 at 9:15 AM, Doss wrote:
> Hi,
>
> I found a work around for our requirement with the help of Transforming
> Result Documents.
>
> https://lucene.apache.org/solr/guide/7_3/transforming-result-documents.html#subquery
>
> I need insights about the performance impact (if any) this is going to
> create. I assume this transformation is happening after the results being
> obtained by the parent query, so there won't be much performance impact it
> will create, but
>
> we are going to use this functionality for a large and busy index, so before
> taking further steps I need expert opinion.
>
> Thanks,
> Doss.
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
