Hi,
in some cases it can be necessary to have the copy field stored. My Solr
instance is used by some legacy applications that need to retrive fields by
some especific field names. That's why i need to mantain 2 copies of the same
field: one with the old name and other for the new name (that is provided by
others applications).
In my case I could work this out at a higher lever but it would be very helpful
it can be solve in the schema.xml.
________________________________________
From: Alessandro Benedetti [benedetti.ale...@gmail.com]
Sent: Wednesday, July 15, 2015 4:39 PM
To: solr-user@lucene.apache.org
Subject: Re: Does update field feature work in a schema with dynamic fields?
Hey Shawn, I was debugging a little bit,this is the problem :
When adding a field from the solr document, to the Lucene one, even if this
document was previously added by the execution of the copy field
instruction to the Lucene Document, this check is carried :
org/apache/solr/update/DocumentBuilder.java:89
// Make sure it has the correct number
if( sfield!=null && !sfield.multiValued() && field.getValueCount() > 1 ) {
throw new SolrException( SolrException.ErrorCode.BAD_REQUEST,
"ERROR: "+getID(doc, schema)+"multiple values encountered for
non multiValued field " +
sfield.getName() + ": " +field.getValue() );
}
This will actually check the Solr Document field.getValueCount(),
ignoring the fact that the field was already added to the Lucene
Document to be indexed.
So the field will be added again.
I understand that doesn't make a lot of sense to store a copy field (
nothing will change from the source field stored content).
But I guess we should try to avoid this anomalies.
The simple solution should be to not execute any copy field
instruction in an updatedDocument.
Unfortunately we don't have any signal in the DocumentBuilder at that
point, that will let us know if the Document is a new one or an
updated one.
What do you think?
Will be easy to have the Document builder aware if it is an add or an
update, and react ?
If not we need to think something else.
Cheers
2015-07-15 15:25 GMT+01:00 Shawn Heisey <apa...@elyograg.org>:
> On 7/15/2015 3:01 AM, Martínez López, Alfonso wrote:
> > <!--Fields-->
> > <field name="id" type="string" indexed="true" stored="true"
> required="true" />
> > <field name="name" type="string" indexed="true" stored="true" />
> > <field name="src_desc" type="string" indexed="true" stored="true" />
> > <field name="_version_" type="long" indexed="true" stored="true" /
> > <!--Dynamic fields definition-->
> > <dynamicField name="src_*" type="string" indexed="true" stored="true"
> multiValued="false" />
> > <dynamicField name="dinamic_*" type="string" indexed="true"
> stored="true" multiValued="false" />
> > <!--Copy fields-->
> > <copyField source="src_*" dest="dinamic_*"/>
>
> <snip>
>
> > And later I update the field 'name' with this command:
> >
> > curl http://<solr_host>:<sorl_port>/solr/default/update?commit=true -H
> "Content-Type: text/xml" --data-binary '<add><doc><field
> name="id">1</field><field name="name"
> update="set">paquico</field></doc></add>'
> >
> > As I do so the doc i retrive from Solr is:
> >
> > <result name="response" numFound="1" start="0" maxScore="1.0">
> > <doc>
> > <str name="id">1</str>
> > <str name="name">paquico</str>
> > <str name="src_desc">friend of mine</str>
> > <arr name="dinamic_desc">
> > <str>friend of mine</str>
> > <str>friend of mine</str>
> > </arr>
> > <long name="_version_">1506750859550130176</long>
> > <float name="score">1.0</float>
> > </doc>
> > </result>
>
> The problem here is that the copyField destination is stored, so you get
> the original value of the destination field plus another copy from
> src_desc.
>
> If you look carefully at the "caveats and limitations" for Atomic
> Updates, you will see that all copyField destinations must be unstored
> for proper operation:
>
> https://wiki.apache.org/solr/Atomic_Updates#Caveats_and_Limitations
>
> It appears that this information was *NOT* in the Solr Reference Guide,
> so I updated the reference guide to include it.
>
>
> https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents
>
> Here's a question for those with more expertise than me: If a copyField
> destination were stored, but not multiValued, and an atomic update was
> attempted, would the update fail entirely? I suspect it would, and I'd
> like to make the ref guide info as accurate as I can.
>
> Thanks,
> Shawn
>
>
--
--------------------------
Benedetti Alessandro
Visiting card - http://about.me/alessandro_benedetti
Blog - http://alexbenedetti.blogspot.co.uk
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario o destinatarios. Si no es vd. el destinatario indicado, queda
notificado que la lectura, utilización, divulgación y/o copia sin autorización
está prohibida en virtud de la legislación vigente. En el caso de haber
recibido este correo electrónico por error, se ruega notificar inmediatamente
esta circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.
This email and any file attached to it (when applicable) contain(s)
confidential information that is exclusively addressed to its recipient(s). If
you are not the indicated recipient, you are informed that reading, using,
disseminating and/or copying it without authorisation is forbidden in
accordance with the legislation in effect. If you have received this email by
mistake, please immediately notify the sender of the situation by resending it
to their email address.
Avoid printing this message if it is not absolutely necessary.
