There should be a number of these in the example schemas, although perhaps
without indexed=“true” in the fieldType...
DateRanges are pretty cool, but this in the “keep it simple” category, you
might just be able to use plain pdates with the standard [time TO time] syntax.
Although when I try
Achieving the use-case is a must. So if here is an alternative to
using solr.DateRangeField,
I'm willing to use it. What do you mean by "pdate" and what is it?
I'm reading this link on how to use DateRangeField but yet it is not
working for me:
https://lucene.apache.org/solr/guide/6_6/working-wi
Thanks a lot.
On Thu, Jul 4, 2019 at 9:19 PM Shawn Heisey wrote:
> On 7/4/2019 9:14 AM, Prince Manohar wrote:
> > I am using Solr version *6.4.2*. I got your answers.
> >
> > I have another question. Can we use a *Range query* on point field?
> >
> > I am trying to do something like
> >
> > *fq=
Hi All,
We have a collection that was created on Solr 7.5, and then Solr was
upgraded to 8.1 . After the upgrade, we're seeing that the stored values of
the fields of documents that existed before the upgrade aren't being stored
when the record is updated, even though the indexed value is.
For ex
I think what Mikhail is asking is whether your use-case would be satisfied
by just indexing a standard pdate rather than a daterange, then querying
by
fq=CC_FILE_DATETIME:[some_date/MONTH TO some_maybe_other_full_date].
With regular pdates, you can use “date math” to round to whatever you want
o
I need both: point in time and range. In both cases, I need to be able to
search between just 2 years, between year-month to year-month-day-time,
etc. So getting my schema right, what and how I index right and the search
syntax right are all important. This is why, in my original post, I shared
Hold on. Do you need a range or just point in time?
On Fri, Jul 5, 2019 at 6:51 PM Steven White wrote:
> Thanks Mikhail. I will read those links and switch over to latest Solr.
>
> Just to be sure, my schema setup and the way I'm indexing the date data are
> not the issue, right?
>
> Steven.
>
On 05/07/2019 14:33, Joseph_Tucker wrote:
Thanks for your help / suggestion.
I'm not sure I completely follow in this case.
SolrJ looks like a method to allow Java applications to talk to Solr, or any
other third party application would simply be a communication method between
Solr and the langu
On 05/07/2019 14:49, Margo Breäs | INDI wrote:
Hi all,
At the moment we are working with Solr version 4.8.1 in combination
with an older version of Intershop.
We have recently migrated our entire shop to a new party, and so there
is room for improvements.
Are there any known issues with u
Thanks Mikhail. I will read those links and switch over to latest Solr.
Just to be sure, my schema setup and the way I'm indexing the date data are
not the issue, right?
Steven.
On Fri, Jul 5, 2019 at 11:05 AM Mikhail Khludnev wrote:
> Hello,
>
> The indexed daterange value is really narrow,
Thanks for bring closure to this. Yeah, “escaping hell” is something that
happens to us all, something that works in a browser doesn’t work
from SolrJ and neither one may work with curl and……
Pretty often, BTW, I look at the Solr log. It takes a little practice to
reconstruct the query, but it’s
There are a _lot_ of changes since 4.8.1.
1> plan on re-indexing the entire corpus. This is required when jumping more
than one major version.
2> Treat it as a green-field application. In particular do not just copy your
schema and config files into 8x and start running. Instead, identify any
Hello,
The indexed daterange value is really narrow, it might not be easy to pick
per se. I'm in doubts regarding " in queries. At least TO syntax expects [
]
You can start from these baseline cases
https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/schema/DateRan
Hi everyone,
I'm using Solr 7.2.1 but can upgrade if I must.
I setup my schema like so:
And indexed my data like so:
doc.addField("CC_FILE_DATETIME", "2019-02-05T12:04:00Z");;
When I try to search against this field, some search are working, others
are not. Here are examples
Hi all,
At the moment we are working with Solr version 4.8.1 in combination with an
older version of Intershop.
We have recently migrated our entire shop to a new party, and so there is room
for improvements.
Are there any known issues with upgrading over that many versions in general,
or with
Thanks for your help / suggestion.
I'm not sure I completely follow in this case.
SolrJ looks like a method to allow Java applications to talk to Solr, or any
other third party application would simply be a communication method between
Solr and the language of your choosing.
I guess what I'm aft
I don't think you should be designing this around DIH. It was never planned
for complex scenarios. Or particularly fault tollerant, which you may need.
Either use SolrJ or a third party tools that integrate with Solr.
Regards,
Alex
On Fri, Jul 5, 2019, 7:43 AM Joseph_Tucker,
wrote:
> What
What is the best way - performance wise - to index data from multiple
databases?
I'm potentially going to have around 50 different data sources grabbing
unique data
Here's what I've roughly designed:
...
I've excluded fields but each entity
Hi we have a new setup of solr 7.7 without cloud in a master/slave setup
Periodically our core stops responding to queries and must be
restarted on the slave.
Two hosts
is06 solr 7.7 master
ss06 solr 7.7 slave
simple replication is setup no solr cloud
so on the primary is06 we see this error
Hello,
I have a collection containing a field called text defined as below in the
schema.xml file:
Here is an example of text: "pam_unix(cron:session): session closed for user
root"
I want to know the number of documents containing the expression "session
closed".
Below the request I use
20 matches
Mail list logo
