Torben,
Denormalization implies copying attrs which are common for a group into the
smaller docs:
doc
str name=setid3/str
str name=attribute_Avalue/str
str name=attribute_Bvalue/str
str name=optionsA/str
str name=value200/str
/doc
doc
str name=setid3/str
str
I Overrrided DefaultSimilarity class to return idf=1 always
Now score is fully dependent on term matching.
If single term is matching, matching docs have same score.
If phrase is matching it has maximum score.
--
View this message in context:
thank you . Hoss
Tokenization is not a problem in english,but in some other languages like
chinese, there are no space to seperate each term in article.Lt is a long
string like this “AABCDAEFSABS”,in which “AA” and BCD ...represent a
meaningful term ,so l want to boost some special and meaningful
On 6 October 2012 20:31, nitin malhotra nitin.rs...@gmail.com wrote:
Hi!
I have a business case to Index the Product Catalogue data using Solr for a
food chain client. The data received is in the form of XML. And the
business requirement for search is that a log in customer on the portal
One approach is to have a multi-valued views field for each document which
indicates which views can see each document, and then apply a filter query
to the user query which specifies the view(s) that that particular user is
permitted based on their logon.
-- Jack Krupansky
-Original
Thanks Gora for a quick response.
The catalogue views are not defined in the structure of the XMLs. The input
to the Solr engine will be a base catalogue system comprising of the entire
set of products. It is totally left for the search module to meet the
business requirement.
For your options
I should also mention that the views field could be an external file
field which reads from a separate file which can be updated without any
re-indexing of the documents so that an admin could change document
visibility on the fly.
See:
On 6 October 2012 21:15, nitin malhotra nitin.rs...@gmail.com wrote:
[...]
For your options mentioned:
1. Different Solr Core would not be possible as these views are not
defined ahead of time in XML.
Is it just that the catalogue views are not defined in the XML,
or that they must be
Hi,
The catalogue views are of dynamic fashion and a fresh update and index
creation can bring in a change in the distribution of the product / records
from one view set to another. There can be modifications for every index
refresh. In such a case is the multi core option suitable to be used ?
Thanks Jack,
I will try to read through this.
Best Regards;
Nitin
On Sat, Oct 6, 2012 at 9:26 PM, Jack Krupansky j...@basetechnology.comwrote:
I should also mention that the views field could be an external file
field which reads from a separate file which can be updated without any
On 6 October 2012 21:53, nitin malhotra nitin.rs...@gmail.com wrote:
Hi,
The catalogue views are of dynamic fashion and a fresh update and index
creation can bring in a change in the distribution of the product / records
from one view set to another. There can be modifications for every index
Sure, you need to define the appropriate delete query for each DIH entry.
Best
Erick
On Fri, Oct 5, 2012 at 5:40 PM, Billy Newman newman...@gmail.com wrote:
Does DIH support only deleting/re-indexing docs of a certain type?
I.E. can I have a DIH for type:vegetable and another for type:mineral
Right. You define three update handlers, something like /update-animal,
/update-mineral, and /update-vegetable. Each one has a separate DIH config.
Each config deletes documents of that type and loads documents of that type.
You will not want to run them at the same time, because a commit in
13 matches
Mail list logo
