antee your code
would be accepted, as a minimum it will require various iterations
of feedback, but you can start the process if you are passionate about it!
Cheers
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*
e-mail
u want to
donate and benefit the broader community (i.e. you get the money from other
projects)
Hope it helps,
Cheers
--
*Alessandro Benedetti*
Director @ Sease Ltd.
*Apache Lucene/Solr Committer*
*Apache Solr PMC Member*
e-mail: a.benede...@sease.io
*Sease* - Informatio
people in our free time purely driven
by passion.
Respect is fundamental, we are not here to be treated aggressively.
Regards
--
Alessandro Benedetti
Apache Lucene/Solr Committer
Director, R&D Software Engineer, Search Consultant
www.sease.io
On Fri, 11 Jun 2021 at 1
if the user needs to limit the search process?"
Can you elaborate?
Cheers
[1] https://xyproblem.info
------
Alessandro Benedetti
Apache Lucene/Solr Committer
Director, R&D Software Engineer, Search Consultant
www.sease.io
On Wed, 9 Jun 2021 at 19:08, wrote:
>
What about external fields?
https://lucene.apache.org/solr/guide/6_6/working-with-external-files-and-processes.html
I admit I have not read in details all the thread, but from a superficial
reading, it could help.
Apologies if it's not helpful enough!
Cheers
On Thu, May 9, 2019 at 12:57 PM Feder
Hi Markus,
I contributed to Solr this exact part :
https://issues.apache.org/jira/browse/SOLR-12238
Patch and Pull Request is attached but it has not been reviewed yet.
Give it a look, and then we can continue the discussion here!
let me know if you feel your requirement is different !
Cheers
O
Why 6.1 should have more bugs than 5.5 ?
6.1 does contain tons of bugfixes and new features.
Of course sperimental features can be buggy, but for the rest I would go
with 6.1 ( which is 5.5 more mature )
If you don't like 6.x you can go with 5.5.2 which have bugfixes backported.
Cheers
On Thu, Ju
h Ante.
>
> I am looking as below .
>
> [image: Inline image 1]
> When user is typing then only matched records should shown.
>
> *Suggestions of the whole content of a field or only few tokens ?*
> Do you want only few tokens or the entire field value ?
> [Bhaskar] I want
I guess you want the entire field
value.
Cheers
>
> Thank you very much.
>
> Regards,
> Bhaskar
>
>
>
> On Mon, Nov 23, 2015 at 10:24 PM, Alessandro Benedetti <
> abenede...@apache.org> wrote:
>
> > Can you list us your requirements ?
> >
>
Can you list us your requirements ?
Is analysis needed in the suggester ?
Do you want infix suggestions ?
Do you want fuzzy suggestions ?
Suggestions of the whole content of a field or only few tokens ?
Starting from that you can take a look to the suggester component and all
the different implem
I would add an additional consideration.
Are we aggregating any of the results ?
Is any use case where we aggregate the results from different Indexes into
one response?
In the case we would need to calculate the aggregation overload.
This means that if the Index is not that big, sometimes is bett
Hi Markus,
what is the logic behind your query parser?
How the query is expected to be rewritten ?
I've never seen that kind of rewritten query, but if you tell us what you
are expecting to rewrite, maybe would be easier to help!
Cheers
On 10 November 2015 at 14:31, Markus Boese wrote:
> Hi,
>
+1 on Jack,
furthermore, are you taking about search or autocomplete ?
If you only need autocompletion on the term, maybe it's even better if you
take a look to the Lucene suggest module !
Cheers
2015-10-05 14:34 GMT+01:00 Jack Krupansky :
> Sounds like you need the edge n-gram filter at index t
reading this : " *unindexed* but stored field of sentences"
Unindexed immediately points to me to the fact you actually do not need a
tokeniser at all.
Just run an external sentence splitter ( in your indexing application), and
store the sentences as different values for a stored field.
Why t
ocessed);
> > }
> >
> > query = new QueryParser("", analyzer).parse(queryStr.trim());
> >
> > ...
> >
> >
> > As far as i understand my problem is, that in my - naive query syntax
> > based solution -
> > i have to use m
sb.append(QueryParser.escape(toEscape.substring(i, i + 1)));
> }
>
> result = sb.toString();
> } else {
> result = QueryParser.escape(toEscape);
> }
> }
>
> return result;
> }
>
> ...
>
> Thanks and Kind regards
>
>
>
phrase.
>
> What do i have to do?
>
> Thanks and Kind regards
>
> On Tue, Jul 21, 2015 at 2:47 PM, Alessandro Benedetti <
> benedetti.ale...@gmail.com> wrote:
>
> > Hey Jack, reading the doc :
> >
> > " Set to true if phrase queries will be au
Hey Jack, reading the doc :
" Set to true if phrase queries will be automatically generated when the
analyzer returns more than one term from whitespace delimited text. NOTE:
this behavior may not be suitable for all languages.
Set to false if phrase queries should only be generated when surround
Hi Yechiel,
if you refers to the same java object instances ( i.e. the same object,
identified by the same reference in the heap space), the answer is no.
The document you send to Lucene to be added to index is a different Object
type from the one you can retrieve from a searcher.
You can index
Hi Diego,
let me try to help :
I find this a little bit confused :
"For our customer it is important to find the word
- *wi-fi* by wi, *fi*, wifi, wi-fi
- jean-pierre by jean, pierre, jean-pierre, jean-*"
But :
"
The (exact) query "*FD-A320-REC-SIM-1*" returns
FD-A320-REC-SIM-1
MIA-*FD-A320-REC-
20 matches
Mail list logo
