t;>>
>>>> (You can also use an "frange" query.)
>>>>
>>>> Then you will have to flatten the database tables. Your Solr schema would
>>>> have a single "merged" record type. You will have to decide whether the
>>>>
ou will have to decide whether the
>>> different record types (tables) will have common fields versus static
>>> qualification by adding a prefix or suffix, e.g., "name" vs. "employee_name"
>>> and "employer_name". The latter has the advantag
ot;type" field since the fields would be empty for
>> records of other types.
>>
>> -- Jack Krupansky
>>
>> -Original Message- From: Stefan Burkard
>> Sent: Wednesday, August 15, 2012 8:12 AM
>> To: solr-user@lucene.apache.org
>> Subject: Ho
he latter has the advantage that you do not have to
> separately specify a table "type" field since the fields would be empty for
> records of other types.
>
> -- Jack Krupansky
>
> -----Original Message- From: Stefan Burkard
> Sent: Wednesday, August 15, 2012 8:12 AM
to
separately specify a table "type" field since the fields would be empty for
records of other types.
-- Jack Krupansky
-Original Message-
From: Stefan Burkard
Sent: Wednesday, August 15, 2012 8:12 AM
To: solr-user@lucene.apache.org
Subject: How to design index for related
Hi solr-users
I have a case where I need to build an index from a database.
***Data structure***
The data is spread across multiple tables and in each table the
records are versioned - this means that one "real" record can exist
multiple times in a table, each with different validFrom/validUntil
