Seriously consider de-normalizing the data at index time. Your
indexing client just accesses both the DB and the file system, selects
the relevant data from each then indexes that data as a _single_
document.
Then there's no joining necessary at query time.
It's a common pattern to do extra work
Thank you Erick. I readed a lot of in the web and I still a litle lost. In
summarizze, I need perform a join (sql join). For the moment, I evaluated
the following alternatives:
1. Alias (first response). I think it doesn't solve the problem, because
I understand this is usefull to union (sql
bq. I don't know if the best approach is combine in index time or in query time
It Depends (tm). What is your goal? Let's say you have db_f1 and fm_f2
(db == from the database and fm = file data).
If you want to form a Solr query like
db_f1:something fm_f2:something_else
you don't have much ch
Thank both.
*"From your problem description, it looks like you want to gather the data
from the DB and filesystem and combine them into a Solr document at index
time, then index that document. " *
Exactly. I don't know if the best approach is combine in index time or in
query time. But I need sea
>From your problem description, it looks like you want to gather the
data from the DB and filesystem and combine them into a Solr document
at index time, then index that document.
Put enough information in Solr to fetch the document as necessary,
often people don't put the entire file in Solr espe
Hi,
I would create a search alias, that contains the latest versions of the
different collections.
See:
https://lucene.apache.org/solr/guide/7_3/collections-api.html#collections-api
Then you use this alias to search for results
You get better results if you define the same schema for all colle
