time, it was 01:00 Day
> 3 here. Faceting puts the event at Day 2 00:00’s bucket, when converted to my
> timezone, puts the event on Day 2. But it was Day 3 here when the event
> happened...
>
> I wish I didn’t bore the hell out of you. Do you have any suggestion to solve
>
ut it was Day 3 here when the event
happened...
I wish I didn’t bore the hell out of you. Do you have any suggestion to solve
this problem? Unfortunately my timestamp field is not a date field and I need
to show the results from my perspective, not from the universal time.
Have a nice day!
Sent from Mail for Windows 10
: Recently, we have switched over to use atomic update instead of re-indexing
: when we need to update a doc in the index. It looks to me that the
: timestamp field is not updated during an atomic update. I have also looked
: into TimestampUpdateProcessorFactory and it looks to me that won&#
I have a timestamp field in my schema to track when each doc was indexed:
Recently, we have switched over to use atomic update instead of re-indexing
when we need to update a doc in the index. It looks to me that the
timestamp field is not updated during an atomic update. I have also looked
It is a date field.
./zahoor
On 19-Apr-2013, at 5:02 PM, Erick Erickson wrote:
> I'm guessing that your timestamp is a tdate, which stores "extra"
> information in the index for fast range searches. What happens if you
> try to facet on just a "date" field?
>
> Best
> Erick
>
> On Thu, Apr
I'm guessing that your timestamp is a tdate, which stores "extra"
information in the index for fast range searches. What happens if you
try to facet on just a "date" field?
Best
Erick
On Thu, Apr 18, 2013 at 8:37 AM, J Mohamed Zahoor wrote:
> Hi
>
> I am using SOlr 4.1 with 6 shards.
>
> i want
Hi
I am using SOlr 4.1 with 6 shards.
i want to find out some "price" stats for all the days in my index.
I ended up using stats component like
"stats=true&stats.field=price&stats.facet=timestamp".
but it throws up error like
Invalid Date String:' #1;#0;#0;#0;'[my(#0;'
My Question is :
Hoss Man suggested a wonderful solution for this need:
Always set update="add" to the field you want to keep (is exists), and use
FirstFieldValueUpdateProcessorFactory in the update chain, after
DistributedUpdateProcessorFactory (so the AtomicUpdate will add the
existing field before, if exists).
Nobody responded my JIRA issue :(
Should I commit this patch into SVN's trunk, and set the issue as Resolved?
On Sun, Feb 17, 2013 at 9:26 PM, Isaac Hebsh wrote:
> Thank you Alex.
> Atomic Update allows you to "add" new values into multivalued field, for
> example... It means that the original
Thank you Alex.
Atomic Update allows you to "add" new values into multivalued field, for
example... It means that the original document is being read (using
RealTimeGet, which depends on updateLog).
There is no reason that the list of operations (add/set/inc) will not
include a "create-only" operat
Unless it is an Atomic Update, right. In which case Solr/Lucene will
actually look at the existing document and - I assume - will preserve
whatever field got already populated as long as it is stored. Should work
for default values as well, right? They get populated on first creation,
then that doc
patch to
>>>>> DistributedUpdateProcessor).
>>>>> It's my first JIRA. please review it...
>>>>> (Or, if someone has an easier solution, tell us...)
>>>>>
>>>>> https://issues.apache.org/jira/browse/SOLR-4468
>>>
ment request (attached a patch to
> > > > DistributedUpdateProcessor).
> > > > It's my first JIRA. please review it...
> > > > (Or, if someone has an easier solution, tell us...)
> > > >
> > > > https://issues.apache.org/jira/browse/SOLR-4
> > (Or, if someone has an easier solution, tell us...)
> > >
> > > https://issues.apache.org/jira/browse/SOLR-4468
> > >
> > >
> > > On Fri, Feb 15, 2013 at 8:13 AM, Isaac Hebsh
> > wrote:
> > >
> > >> Hi.
&
t JIRA. please review it...
> > (Or, if someone has an easier solution, tell us...)
> >
> > https://issues.apache.org/jira/browse/SOLR-4468
> >
> >
> > On Fri, Feb 15, 2013 at 8:13 AM, Isaac Hebsh
> wrote:
> >
> >> Hi.
> >>
> >>
ent request (attached a patch to
> DistributedUpdateProcessor).
> It's my first JIRA. please review it...
> (Or, if someone has an easier solution, tell us...)
>
> https://issues.apache.org/jira/browse/SOLR-4468
>
>
> On Fri, Feb 15, 2013 at 8:13 AM, Isaac Hebsh wrote:
>
> Hi.
>
> I have a 'timestamp' field, which is a date, with a default value of 'NOW'.
> I want it to represent the datetime when the item was inserted (at the
> first time).
>
> Unfortunately, when the item is updated, the timestamp is changed...
>
> How can I implement INSERT TIME automatically?
>
;problem".
Well, I must be careful when using this field.
Thanks for your answer,
Frederico
-Original Message-
From: Jan Høydahl / Cominvent [mailto:jan@cominvent.com]
Sent: quarta-feira, 11 de Agosto de 2010 12:17
To: solr-user@lucene.apache.org
Subject: Re: timestamp field
Hi,
be careful when using this field.
Thanks for your answer,
Frederico
-Original Message-
From: Jan Høydahl / Cominvent [mailto:jan@cominvent.com]
Sent: quarta-feira, 11 de Agosto de 2010 12:17
To: solr-user@lucene.apache.org
Subject: Re: timestamp field
Hi,
Which time zone are you loc
Hi,
Which time zone are you located in? Do you have DST?
Solr uses UTC internally for dates, which means that "NOW" will be the time in
London right now :) Does that appear to be right 4 u?
Also see this thread: http://search-lucene.com/m/hqBed2jhu2e2/
--
Jan Høydahl, search solution architect
Hi,
I have on my schema
This field is returned as
2010-08-11T10:11:03.354Z
For an article added at 2010-08-11T11:11:03.354Z!
And the server has the time of 2010-08-11T11:11:03.354Z...
This is a w2003 server using solr 1.4.
Any guess of what could be wrong here?
Tha
21 matches
Mail list logo
