Hello
I think you need to use "org.hsqldb.jdbc.jdbcDriver" instead of "
org.hsqldb.jdbcDriver".
Deepak
"The greatness of a nation can be judged by the way its animals are treated
- Mahatma Gandhi"
+91 73500 12833
deic...@gmail.com
Facebook: https://www.facebook.com/deicool
LinkedIn: www.linkedi
Hey
It might be possible *allText* does not consider them *()* as text. You
might have to try something else (possibly String)
Deepak
"The greatness of a nation can be judged by the way its animals are treated
- Mahatma Gandhi"
+91 73500 12833
deic...@gmail.com
Facebook: https://www.facebook.c
Hi
Thx for the snippet of SolrJ code for Core Creation...
Request Do we have a Solr/Solrj internal implementation of AAA on this Core
creation
Reason : I want restricted access for core creation.
Do we have a GIT repository with these sorts of java-solr example.. to try
with regards
karthik
On 10/18/2021 11:24 PM, nskarthik wrote:
Thx for the snippet of SolrJ code for Core Creation...
Request Do we have a Solr/Solrj internal implementation of AAA on this Core
creation
I have never used that capability in Solr. It's there, but I have found
that the best way to secure Solr is by
Okay, I think we have a suspect!
I confirmed that the replicas are read-only and no updates are expected
from queries. Then I took a look at replication status and noticed the
following:
"replicationFailedAtList":["Mon Oct 18 12:35:44 UTC 2021",
"Mon Oct 18 12:01:22 UTC 2021",
Unfortunately I can't change the type of the allText field to string. We need
the features that come with it being a text field.
(We did try changing it to string just to see what would happen -- it made the
problem worse, and solr still didn't handle the escaped parentheses properly)
We're us
Your field type eats/removes parentheses - so there's no way to search for
them.
Adjustments will need to be made one way or another to get parentheses
indexed and queried.
Erik
On Tue, Oct 19, 2021, 11:27 Casteel, Kayla Lynne
wrote:
> Unfortunately I can't change the type of the allText f
Oh no... if you don't mind, can you elaborate on that? Is it tthe
solr.TextField type we're using that's causing this?
I'm very new to solr and I haven't seen this in the documentation.
Thank you,
Kayla Casteel
From: Erik Hatcher
Sent: Tuesday, October 19, 20
One possibility could be to borrow an idea from the NLP world, and
pre-process parenthesis to -LRB- and -RRB- tokens (and square and curly to
their corresponding forms). Bypasses issues of escaping but needs
reindexing, and preprocessing the query.
-sujit
On Tue, Oct 19, 2021 at 8:27 AM Casteel,
You can use copyField in your schema to have the same incoming text indexed
as different field types. As long as you don't need the features of the
text field and the literal parentheses at the same time, it's just a matter
of querying the field that has the analysers you want for a particular use
Hi,
We are using Solr 8.8.2. An automated scan indicated that this version of
Solr is vulnerable to the issue described in
https://issues.apache.org/jira/browse/LUCENE-9981 where certain searches
can be extremely slow.
Does anyone know if this issue will only occur with true regular expression
qu
It is the StandardTokenizer that is eating the parentheses, both at index and
query time. If you want to do exact matching, a string type is probably what
you want.
A tokenized field is normally not a good candidate for facets, because usually
the cardinality for such a field is VERY high. Face
On 10/11/2021 2:53 PM, Shawn Heisey wrote:
I would like to request help from the community on something. I'm not
in a position to do the kind of testing that I want, as I no longer have
access to Solr servers with large amounts of data.
Because of the small scale of my Solr server, I don't th
13 matches
Mail list logo
