: Here are the results with the debugQuery=true; with debugging off, there are
: no results.
I don't understand what you mean. According to this response, with
debugQuery=true, there are not results matching your query...
:
: The elevated result appears in the queryBoost section but not i
I can guarantee you that the ID is unique and it exists in that index.
--
View this message in context:
http://lucene.472066.n3.nabble.com/QueryElevationComponent-results-only-show-up-with-debug-true-tp4087531p4087565.html
Sent from the Solr - User mailing list archive at Nabble.com.
Sure,
Here are the results with the debugQuery=true; with debugging off, there are
no results.
The elevated result appears in the queryBoost section but not in the result
section:
0
0
true
xml
100
*,[elevated]
text
true
0
gangnam
: What am I doing wrong?
: query:
:
http://localhost:8080/solr/Profiles/elevate?q=gangnam+style&fl=*,[elevated]&wt=xml&start=0&rows=100&enableElevation=true&forceElevation=true&df=text&qt=edismax&debugQuery=true
You've shown up the configs you are using, and the query you executed, and
you've sa
You shouldn't try copying files around, your comment that you
" tried replacing QueryElevationComponent.java" leads me to
think you tried that. Instead, I notice that there's a SOLR-2949.3x
patch. If you want to try that, you can apply the patch to the 3.x code
line. See "working with patches" at
h
Hi Erick,
I cannot migrate to 4.0-ALPHA or 4.0-BETA because of the dependency in
configuration as part of indexing in solrconfig.xml and schema.xml.
When I try to use 4.0 version, I get a series of errors that pops up. Also
I cannot change the entire configuration files that are available to me.
no, it's not. The fix version is 4.0-ALPHA
So you can test this pretty easily for yourself by getting 4.0
alpha/beta or RC1 and giving it a whirl...
Best
Erick
On Thu, Oct 4, 2012 at 10:10 AM, vasokan wrote:
> Hi,
>
> I am using the following version of Solr.
>
> Solr Specification Ver
On Apr 26, 2012, at 2:56 PM, srinir wrote:
> Can anyone help me out in understand the fix to QueryElevationComponent (in
> Solr 4.0) to make it work for distributed search.
>
>
https://github.com/apache/lucene-solr/commit/229ed68c31b346611c505ca9766871cec713a850
- Mark Miller
lucidimaginatio
Can anyone help me out in understand the fix to QueryElevationComponent (in
Solr 4.0) to make it work for distributed search.
--
View this message in context:
http://lucene.472066.n3.nabble.com/QueryElevationComponent-and-distributed-search-tp3936998p3942221.html
Sent from the Solr - User mailing
Hi Mark
Thanks a lot for your response. Yeah, I was looking for distributed
methods. I would like to know the reason why it didn't work in Solr 3.6.
When i try (i only have solar 3.6)
Note: the same query below works when i replace elevate with select, by
which i am assuming my setup is correct.
On Apr 25, 2012, at 5:54 PM, srinir wrote:
> Can anyone tell me whether support for distributed search is added to
> QueryElevationComponent in solr 4.0 ?
Yes.
>
> I looked at QueryElevationComponent code in trunk and it doesnt seem to have
> any code to support distributed search. Am I missi
Can anyone tell me whether support for distributed search is added to
QueryElevationComponent in solr 4.0 ?
I looked at QueryElevationComponent code in trunk and it doesnt seem to have
any code to support distributed search. Am I missing something here ?
--
View this message in context:
http:/
I'd read that too, but in the debug data queryBoosting is showing
matches on our int typed identifiers (though it does show it as
123456). Is the problem that it can match against an
integer, but it can't reorder them in the results? This seems unlikely
as using a standard query and elevation
Maybe some things to try:
* make sure your uniqueKey is string field type (ie if using int it will not
work)
* forceElevation to true (if sorting)
- Jon
On Mar 9, 2010, at 12:34 AM, Ryan Grange wrote:
> Using Solr 1.4.
> Was using the standard query handler, but needed the boost by field
> fu
Hi,
On May 12, 2009, at 12:33 , Nicolas Pastorino wrote:
Hi,
On May 7, 2009, at 6:03 , Noble Paul നോബിള്
नोब्ळ् wrote:
going forward the java based replication is going to be the preferred
means replicating index. It does not support replicating files in the
dataDir , it only supports re
Hi,
On May 7, 2009, at 6:03 , Noble Paul നോബിള്
नोब्ळ् wrote:
going forward the java based replication is going to be the preferred
means replicating index. It does not support replicating files in the
dataDir , it only supports replicating index files and conf files
(files in conf dir). I
going forward the java based replication is going to be the preferred
means replicating index. It does not support replicating files in the
dataDir , it only supports replicating index files and conf files
(files in conf dir). I was unaware of the fact that it was possible to
put the elevate.xml in
On May 6, 2009, at 15:17 , Noble Paul നോബിള്
नोब्ळ् wrote:
Why would you want to write it to the data dir? why can't it be in the
same place (conf) ?
Well, fact is that the QueryElevationComponent loads the
configuration file ( elevate.xml ) either from the data dir, either
from the con
Why would you want to write it to the data dir? why can't it be in the
same place (conf) ?
On Wed, May 6, 2009 at 6:43 PM, Nicolas Pastorino wrote:
> Hello,
>
> On May 6, 2009, at 15:02 , Noble Paul നോബിള് नोब्ळ् wrote:
>
>> The elevate.xml is loaded from conf dir when the core is reloaded . if
Hello,
On May 6, 2009, at 15:02 , Noble Paul നോബിള്
नोब्ळ् wrote:
The elevate.xml is loaded from conf dir when the core is reloaded . if
you post the new xml you will have to reload the core.
A simple solution would be to write a RequestHandler which extends
QueryElevationComponent which c
The elevate.xml is loaded from conf dir when the core is reloaded . if
you post the new xml you will have to reload the core.
A simple solution would be to write a RequestHandler which extends
QueryElevationComponent which can be a listener for commit and call an
super.inform() on that event
On F
Hi,
On Apr 10, 2009, at 16:51 , Ryan McKinley wrote:
On Apr 10, 2009, at 7:48 AM, Nicolas Pastorino wrote:
Hello !
Browsing the mailing-list's archives did not help me find the
answer, hence the question asked directly here.
Some context first :
Integrating Solr with a CMS ( eZ Publish
On Apr 10, 2009, at 7:48 AM, Nicolas Pastorino wrote:
Hello !
Browsing the mailing-list's archives did not help me find the
answer, hence the question asked directly here.
Some context first :
Integrating Solr with a CMS ( eZ Publish ), we chose to support
Elevation. The idea is to be a
On Nov 23, 2008, at 3:06 PM, Paolo Ruscitti wrote:
Thanks Ryan for your answer.
The only thing that may be weird is that if you id field is named
"myid",
your elevate.xml file still refers to "id" as the unique key. Is
that what
you are refering to?
yes, my id field is named "myid", but
Thanks Ryan for your answer.
>The only thing that may be weird is that if you id field is named "myid",
your elevate.xml file still refers to "id" as the unique key. Is that what
you are refering to?
yes, my id field is named "myid", but elevate.xml expects its name is "id" .
Please find below
hymm -- that *should* not be the case. The id field in
QueryElevationComponent uses the globally defined field:
SchemaField sf = core.getSchema().getUniqueKeyField();
...
idField = sf.getName().intern();
The only thing that may be weird is that if you id field is named
"myid", y
26 matches
Mail list logo
