0

I have multivalued fields in my solr datasource. sample is

  <doc>
    <str name="id">23606</str>
    <arr name="fecha_referencia">
        <str>2020-05-24</str>
        <str>2018-01-18</str>
        <str>1997-07-22</str>
    </arr>
    <arr name="tipo_de_fecha">
        <str>Publicacion</str>
        <str>Creación</str>
        <str>Edicion</str>
    </arr>
    </doc>

But the point is that when I do a search I want the date 2020-05-24 to belong to the "Publication" date type, because solr does not handle positions but rather looks for at least one match between the Arrays of reference_date and date_type.

The question is: how could i preserve ordering/mapping in multivalued in solr?

This is my data-config.xml structure:

<dataConfig>
<dataSource  type="JdbcDataSource" driver="org.postgresql.Driver" url="jdbc:postgresql://10.152.11.47:5433/metadatos" user="us_me" password="ntm" URIEncoding="UTF-8" />
    <document >
       <entity name="tr_ident" query="SELECT id_ident, titulo,proposito,descripcion,palabra_cve
        FROM ntm_p.tr_ident">
            <field column="id_ident" name="id_ident" />
            <field column="titulo" name="titulo" />
            <field column="proposito" name="proposito" />      
       <entity name="ti_fecha_evento"
              query="select tipo_fecha,fecha_referencia from ntm_p.ti_fecha_evento where id_fecha_evento='${tr_ident.id_ident}'">
            <field column="fecha_referencia" name="fecha_referencia" />
            <entity name="tc_tipo_fecha" query="select des_tipo_fecha,id_tipo_fecha from ntm_p.tc_tipo_fecha where id_tipo_fecha='${ti_fecha_evento.tipo_fecha}'">
                <field column="id_tipo_fecha" name="id_tipo_fecha" />
                    </entity>
           </entity>
      </entity>
    </document>
</dataConfig>

1 Answers1

0

It's important to note that ordering is preserved as long as the field is stored (and not just have docValues enabled) - the first date will be the first date that was sent to the field, which can then be mapped to the first field in the second field.

However, what you're looking for is a dependent query, where each field is queried in relation to the other. In that case, index each value as a field by itself - either by explicitly defining them, or by using a dynamic field name.

fecha_referencia_publicacion: "2020-05-24",
fecha_referencia_creacion: "2018-01-18",
...

That way you can perform any range queries and faceting on the field as usual.

Alternatively, if you only need exact hits, you can index a concatenated value where both the type and the date is indexed into the same field:

fecha_referencia: "Publicacion_2020-05-24"
MatsLindh
  • 49,529
  • 4
  • 53
  • 84
  • It is a very good answer, I show you more detail about my problem: I am indexing via DIH because the main source is postgresql, so I am saving the dates and data_type in a multivalued field because its origin comes from an m to m relation of postgresql, As you mentioned, it could be indexed by concatenating but since I use date ranges I find it difficult to do it by that method. So I don't know if it can be done by means of a field and with transformer separate them into auxiliary fields. Could you give me a contact to talk about this please? I'm desperate! – sergio briano Aug 18 '20 at 20:51
  • I'm not sure if you can use the TemplateTransformer inside the field name, but it'd be something like `field_name_${ti_fecha_evento.fecha_referencia}`. You'll also need to add transformer="TemplateTransformer"` to your entity definition. Another option is to [use a script processor to transform the field names](https://stackoverflow.com/questions/7917317/dynamic-column-names-using-dih-dataimporthandler) (which allows you to attach arbitrary Javascript to the processing pipeline). – MatsLindh Aug 18 '20 at 21:10
  • Interesting friend, I will continue investigating more about script transformers to build dynamic fields. Because I do not see another alternative to bring me those multiple values ​​in separate values ​​considering that the source of the data is a relational database – sergio briano Aug 19 '20 at 14:23