you can try out : https://github.com/geek4377/jetty-solr.git
I have tested it out briefly and seems to work fine.
@all
anyone who wants to test jetty 8 with solr 3.6, all feedback, comments
welcome :)
On Fri, May 25, 2012 at 8:13 PM, Maciej Lisiewski wrote:
> I have just noticed that Solr 3.6
Hey Safdar,
This question is best asked on the Apache Solr mailing lists. I
believe you'll get better responses there, so I've redirected to
Solr's own list (solr-user[at]lucene.apache.org).
BCC'd common-user[at]hadoop.apache.org and CC'd you in case you
haven't subscribed to Solr.
On Sat, Jun 2
There are a number of ways this can be accomplished, including as a
preprocessor or a custom update processor, but you may be able to get by
with a tokenized field without term vectors combined with a "keep words"
filter and an index-time synonym filter that uses "replace mode".
So, in additio
One important footnote: the "keep words/synonym analyzer" approach will
index the desired keywords for efficient search, but the stored value that
would be returned in response to a query request would be the full original
text. If you wish to return only the final list of matched synonyms, you
If you go down the keep-word route you can return the "tags" to the
front end app using a facet field query. This often fits with many
use-cases for doc tags.
lee c
On 23 June 2012 22:37, Jack Krupansky wrote:
> One important footnote: the "keep words/synonym analyzer" approach will
> index the
Or do a copyField to a "string" field and do a prefix wildcard query using
the year: publication-date_s:2010*.
If you are using the LucidWorks Enterprise product, their query parser
understands date fields and you can simply type: publication-date:2010
-- Jack Krupansky
-Original Messag
To do exactly what you want, you might have to do a custom analyzer. To
Solr, even with the WDF filter in the example text_en_splitting field type,
which tokenizes "A0001487" as "a 0001487", the "0001487" is simply text
characters, not a number. You could develop your own "number simplifier"
fi
As my index is actually out :'( I can't test it but with your first
method (wildcard) the possibility to search with range becomes
not possible. So I will pre-process my request with the standard date
format field.
Little question: is it always necessary to write:
i.e. 2001-01-23T23:59:59Z
is e
see: https://issues.apache.org/jira/browse/SOLR-2701.
But there's an easier alternative. Just have a _very special_ document
with a known that you index at the end of the run that
1> has no fields in common with any other document (except uniqueKey)
2> contains whatever data you want to carry arou
You're probably being fooled by the fact that displaying the field
as part of a returned document displays the _stored_ information,
a verbatim copy of the input. To see what's actually in your index,
look with, say, Luke, or the admin/schema browser link or the
TermsComponent.
Best
Erick
On Fri,
Hmmm, you haven't said which version of Solr you use, but according to:
https://issues.apache.org/jira/browse/SOLR-866
it's not supported. But I think the new 4.0 stuff doesn't use the
"sidecar" index
to store this stuff, it just walks the internal data structures for
that field so
it may never be
"is it always necessary to write: i.e. 2001-01-23T23:59:59Z?" (rather than
"2001-01-23")
Unfortunately, today, yes.
There is actually a DateField.parseDateLenient method that supports parsing
of "2001-01-23", but it is not used on the normal code path - for reasons
unknown, but is used for fu
Using 3.5 (also tried trunk), I have the following charFilter defined
on my fieldType (just extended text_general to keep things simple):
The intent of this charFilter is to match any characters that are
repeated in a string more than twice and collapse down to a max of
two, i.e.
foooba =>
Please 1) make sure with a separate program that these are the right
Java regex patterns, and 2) write a unit test with all of the cases
you expect this to handle. Then file a JIRA with the unit test code.
On Sat, Jun 23, 2012 at 5:11 PM, Timothy Potter wrote:
> Using 3.5 (also tried trunk), I ha
Solr does not "ship with anything" as a product. It includes an old
Jetty in the example. The feature set in Jetty has not held back
showing an example of Solr features, so it has not been a priority. If
you supply a patch, that is different :) Especially if the patch shows
how to get all of the Je
On 23 June 2012 17:20, Lance Norskog wrote:
> Solr does not "ship with anything" as a product. It includes an old
> Jetty in the example. The feature set in Jetty has not held back
> showing an example of Solr features, so it has not been a priority. If
> you supply a patch, that is different :)
The char filter's attribute name is "replacement", not "replaceWith". I
tried it and it seems to work fine (with Solr 3.6).
See:
http://lucene.apache.org/solr/api/org/apache/solr/analysis/PatternReplaceCharFilterFactory.html
-- Jack Krupansky
-Original Message-
From: Timothy Potter
17 matches
Mail list logo
