Hello Peter,
by using the existing SynonymFilterFactory, it is not possible to use a
database instead of a text file. This file will be read at startup and
the internal synonym catalogue (SynonymMap) will be created.
You could create your own filter factory that could create the needed
synonym ca
Hi Brad,
I was trying this, too, and there is a possibility how to get multi-term
synonyms to work properly. I wrote my solution already on this list.
My solution was as follows:
[cite]
after your hints that had partially confirmed my considerations, I had
made some tests with the FieldQParser.
Hi Stefan,
you don't need to convert the Java objects built from the result
returned as Javabin. Instead of this, you could easily use the JSON
return format by setting "wt=json". See also at [0] for more information
about this.
Patrick
[0] http://wiki.apache.org/solr/SolJSON
SGE0 schrieb:
>
Thanks Hoss,
after your hints that had partially confirmed my considerations, I had
made some tests with the FieldQParser. At the beginning, I had have some
problems, but finally, I was able to solve the problem of multi-word
synonyms at query time in a way that is suitable for us - and possibly
f
ery time.
Patrick
Koji Sekiguchi schrieb:
> Hi Patrick,
>
> Why don't you define:
>
> foo bar, foo_bar (and expand="true")
>
> instead of:
>
> foo bar=>foo_bar
>
> in only indexing side? Doesn't it make a change for the better?
>
Hi list,
is there any possibility to get highlighting also for the query string?
Example:
Query: fooo bar
Tokens after query analysis: foo[0,4], bar[5,8]
Token "foo" matches a token of one of the queried fields.
-> Query higlighting: "fooo"
Thanks, Patrick
to add it to the query
> chain only. Than your index still preserves the original data.
>
> Cheers,
> Chantal
>
> Patrick Jungermann schrieb:
>> Hi Koji,
>>
>> using phrase queries is no alternative for us, because all query parts
>> has to be optional parts.
ng within /admin/analysis.jsp view.
Patrick
Koji Sekiguchi schrieb:
> Patrick,
>
>> parsedQueryString was something similar to "field:foo field:bar". At
>> index time, it works like expected.
>
> I guess because you are searching q=foo bar, this causes OR query
Hi list,
I worked on a field type and its analyzing chain, at which I want to use
the SynonymFilter with entries similar to:
foo bar=>foo_bar
During the analysis phase, I used the /admin/analysis.jsp view to test
the analyzing results produced by the created field type. The output
shows that a q
Hi Bern,
the problem is the character sequence "--". A query is not allowed to
have minus characters that consequent upon another one. Remove one minus
character and the query will be parsed without problems.
Because of this parsing problem, I'd recommend a query cleanup before
the submit to the
10 matches
Mail list logo
