Hi Eric,
If you want a query informing one customer of its product row at any given
time, the easiest way is to filter on submission date greater than this
customer's and return the result count. If you have 500 products with an
earlier submission date, your row number is 501.
Hope this helps,
oyé : vendredi 22 juillet 2011 16:42
À : solr-user@lucene.apache.org
Objet : Re: commit time and lock
On 7/22/2011 8:23 AM, Pierre GOSSE wrote:
> I've read that in a thread title " Weird optimize performance degradation",
> where Erick Erickson states that "Older versio
vendredi 22 juillet 2011 15:45
À : solr-user@lucene.apache.org
Objet : Re: commit time and lock
Hello,
Pierre, can you tell us where you read that?
"I've read here that optimization is not always a requirement to have an
efficient index, due to some low level changes in lucene 3.xx"
Marc.
On Fr
inished
optimization process.
regards
Jonty
On Fri, Jul 22, 2011 at 2:44 PM, Pierre GOSSE wrote:
> Solr still respond to search queries during commit, only new indexations
> requests will have to wait (until end of commit?). So I don't think your
> users will experience incr
Solr still respond to search queries during commit, only new indexations
requests will have to wait (until end of commit?). So I don't think your users
will experience increased response time during commits (unless your server is
much undersized).
Pierre
-Message d'origine-
De : Jonty
Hi,
Have you check the queries by using the debugQuery=true parameter ? This could
give some hints of what is searched in both cases.
Pierre
-Message d'origine-
De : cnyee [mailto:yeec...@gmail.com]
Envoyé : vendredi 22 juillet 2011 05:14
À : solr-user@lucene.apache.org
Objet : What is
instances ) share a single index file to search on it
without interfering each other
Regards,
JAME VAALET
Software Developer
EXT :8108
Capital IQ
-Original Message-----
From: Pierre GOSSE [mailto:pierre.go...@arisem.com]
Sent: Tuesday, July 05, 2011 5:12 PM
To: solr-user@lucene.apache.org
S
request from different apps
, can this be used.
Regards,
JAME VAALET
-Original Message-----
From: Pierre GOSSE [mailto:pierre.go...@arisem.com]
Sent: Tuesday, July 05, 2011 3:52 PM
To: solr-user@lucene.apache.org
Subject: RE: searching a subset of SOLR index
The limit will always be l
The limit will always be logical if you have all documents in the same index.
But filters are very efficient when working with subset of your index,
especially if you reuse the same filter for many queries since there is a cache.
If your subsets are always the same subsets, maybe your could use
> I think there are reasons to use seperate indexes for each document type
> but do combined searches on these indexes
> (for example if you need separate TFs for each document type).
I wonder if in this precise case it wouldn't be pertinent to have a single
index with the various document types
out the quotes):
"0176 R3 1.5 TO "
Searching for "3 1 15" returns a match with "empty" highlight.
Searching for "3 1 15"~1 returns a match with highlight.
Can anyone see anything that I'm missing?
Thanks,
P.
On Thu, May 12, 2011 at 12:27 PM, Pierre
g special ? a tokenizer or filter
that could add some token in your indexed text but not in your query, like for
example a WordDelimiter present in and not ?
Pierre
-Message d'origine-
De : Pierre GOSSE [mailto:pierre.go...@arisem.com]
Envoyé : jeudi 12 mai 2011 18:21
À : solr-user@
> In fact if I did "3 1 15"~1 I do get snipet also.
Strange, I had a very similar problem, but with overlapping tokens. Since
you're using the standard "text" field, this should be you're case.
Maybe you could have a look at this issue, since it sound very familiar to me :
https://issues.apache
For (a) I don't think anything exists today providing this mechanism.
But (b) is a good description of the dismax handler with a MM parameter of 66%.
Pierre
-Message d'origine-
De : Mark Mandel [mailto:mark.man...@gmail.com]
Envoyé : mercredi 13 avril 2011 10:04
À : solr-user@lucene.ap
Look like special chars are filtered at index time and not replaced by space
that would keep correct offset of terms. Can you paste here the definition of
the fieldtype in your shema.xml ?
Pierre
-Message d'origine-
De : pottw...@freenet.de [mailto:pottw...@freenet.de]
Envoyé : lundi
I do have the xml preamble in my config
file in conf/Catalina/localhost/ and solr starts ok with Tomcat 7.0.8. Haven't
try with 7.0.11 yet.
I wonder why your exception point to line 4 column 6, however. Shouldn't it
point to line 1 column 1 ? Do you have some blank lines at the start of your
estigating commit serialisation, is because we want to
know whether the commit requests will be blocked until the previous ones
finish.
Cheers,
- Savvas
On 9 February 2011 15:44, Pierre GOSSE wrote:
> > However, the Solr book, in the "Commit, Optimise, Rollback" section
> r
> However, the Solr book, in the "Commit, Optimise, Rollback" section reads:
> "if more than one Solr client were to submit modifications and commit them
> at similar times, it is possible for part of one client's set of changes to
> be committed before that client told Solr to commit"
> which su
Yes, I see I didn't understand that facet.query parameter.
Have you consider submitting two queries ? One for results with q.op=OR, one
for faceting with q.op=AND ?
-Message d'origine-
De : Grijesh [mailto:pintu.grij...@gmail.com]
Envoyé : vendredi 4 février 2011 10:42
À : solr-user@lu
Using a facet query like
facet.query=+water +treatement +plant
... should give a count of 0 to documents not having all tree terms. This could
do the trick, if I understand how this parameter works.
20 matches
Mail list logo
