Re: [SOLR-8.5.2] Commit through curl command is causing delay in issuing commit
Hi All, Till we investigate further about this issue. Can anyone please share what other ways we can issue a commit or point me to existing documents that have a relevant example. Regards, Raj -- Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Collection reload issue
Hi, I am using solr 8.1 I ran a collection reload operation: admin/collections?action=RELOAD==1000'. when I checked on the task status, it shows that it's still running: admin/collections?action=REQUESTSTATUS=1000' It's been showing that this task is in running state for the last few days. I am not why the task shows as running. Is it hanging? How can I tell what's the real status of the task (running, failed or completed)? Please advise, Thanks, Moulay
Re: DIH and UUIDProcessorFactory
On 12/12/2020 2:30 PM, Dmitri Maziuk wrote: Right, ```Every update request received by Solr is run through a chain of plugins known as Update Request Processors, or URPs.``` The part I'm missing is whether DIH's 'name="/dataimport"' counts as an "Update Request", my reading is it doesn't and URP chain applies only to ' If you define an update chain as default, then it will be used for all updates made where a different chain is not specifically requested. I have used this personally to have my custom update chain apply even when the indexing comes from DIH. I know for sure that this works on 4.x and 5.x versions; it should work on newer versions as well. Thanks, Shawn
Re: Copyfields, will there be any difference between source and dest if they are switched?
On 12/11/2020 2:38 PM, ufuk yılmaz wrote: My question is, will there be any difference on the resulting indexed documents if I switched source and dest fields in copyField directive? My understanding is copyField operates on raw data arriving at Solr as is, and field declarations themselves decide what to do with it, so there shouldn’t be any difference, but I’m currently investigating an issue which, Presumably your indexing includes place.name but does not contain place.name_orig in the fields that are sent to Solr for indexing. If that's the case, then reversing the fields in the copyField will leave place.name_orig empty. If the indexed data does contain both fields, then the target field would contain the data twice, and if the target field is not multiValued, then indexing will fail. - Same data is indexed in two different collections, one uses a copyField directive like above - Other one don’t use copyField, but same value is sent both in place.name and place.name_orig fields during indexing But I’m seeing some slight differences in resulting documents, mainly in casing between i and İ. Analysis does not affect document data in the results. The data you see in results will be exactly what was originally sent. The only way Solr can change stored data is through the use of Update Processors defined in solrconfig.xml ... analysis defined in the schema will not affect document data in search results. Thanks, Shawn
Re: DIH and UUIDProcessorFactory
On 12/12/2020 2:50 PM, Shawn Heisey wrote: The only way I know of to use an update processor chain with DIH is to set 'default="true"' when defining the chain. I did manage to find an example with the default attribute, in javadocs: https://lucene.apache.org/solr/5_0_0/solr-core/org/apache/solr/update/processor/UpdateRequestProcessorChain.html Right, ```Every update request received by Solr is run through a chain of plugins known as Update Request Processors, or URPs.``` The part I'm missing is whether DIH's 'name="/dataimport"' counts as an "Update Request", my reading is it doesn't and URP chain applies only to ' Dmitri
Re: DIH and UUIDProcessorFactory
On 12/12/2020 12:54 PM, Dmitri Maziuk wrote: is there an easy way to use the stock UUID generator with DIH? We have a hand-written one-liner class we use as DIH entity transformer but I wonder if there's a way to use the built-in UUID generator class instead. From the TFM it looks like there isn't, is that correct? The only way I know of to use an update processor chain with DIH is to set 'default="true"' when defining the chain. I did manage to find an example with the default attribute, in javadocs: https://lucene.apache.org/solr/5_0_0/solr-core/org/apache/solr/update/processor/UpdateRequestProcessorChain.html If there is another way to specify the chain to use with DIH, I do not know about it. I am always learning new things, something might exist that I have never seen. Thanks, Shawn
Re: DIH and UUIDProcessorFactory
Why not? You should be able to put an URP chain after DIH, the usual way. Is that something about UUID that is special? Regards, Alex On Sat., Dec. 12, 2020, 2:55 p.m. Dmitri Maziuk, wrote: > Hi everyone, > > is there an easy way to use the stock UUID generator with DIH? We have a > hand-written one-liner class we use as DIH entity transformer but I > wonder if there's a way to use the built-in UUID generator class instead. > > From the TFM it looks like there isn't, is that correct? > > TIA, > Dmitri >
DIH and UUIDProcessorFactory
Hi everyone, is there an easy way to use the stock UUID generator with DIH? We have a hand-written one-liner class we use as DIH entity transformer but I wonder if there's a way to use the built-in UUID generator class instead. From the TFM it looks like there isn't, is that correct? TIA, Dmitri
Re: Function Query Optimization
Hi, looking at this sample it seems you have just one document for '12345',
one for '23456' and so on so forth. If this is true, why don't just try
with a subquery
https://lucene.apache.org/solr/guide/6_6/transforming-result-documents.html#TransformingResultDocuments-_subquery_
On Fri, Dec 11, 2020 at 3:31 PM Jae Joo wrote:
> I have the requirement to create field - xyz to be returned based on the
> matched result.
> Here Is the code .
>
> XYZ:concat(
>
> if(exists(query({!v='field1:12345'})), '12345', ''),
>
> if(exists(query({!v='field1:23456'})), '23456', ''),
>
> if(exists(query({!v='field1:34567'})), '34567', ''),
>
> if(exists(query({!v='field:45678'})), '45678','')
> ),
>
> I am feeling this is very complex, so I am looking for some smart and
> faster ideas.
>
> Thanks,
>
> Jae
>
--
Vincenzo D'Amore
