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
It is natural part of the update model for Solr (and for many other search
engines). Solr does not do updates. It does add, replace, and delete.
Every document is processed as if it was new. If there is already a document
with that id, then the new document replaces it. The existing documents ar
The component who sends the document does not know whether it is a new
document or an update. These are my internal constraints.. But, guys, I
think that it's a basic feature, and it will be better if Solr will support
it without "external help"...
On Sun, Feb 17, 2013 at 12:37 AM, Upayavira wro
I think what Walter means is make the thing that sends it to Solr set
the timestamp when it does so.
Upayavira
On Sat, Feb 16, 2013, at 08:56 PM, Isaac Hebsh wrote:
> Hi,
> I do have an externally-created timestamp, but some minutes may pass
> before
> it will be sent to Solr.
>
>
> On Sat, Feb
Hi,
I do have an externally-created timestamp, but some minutes may pass before
it will be sent to Solr.
On Sat, Feb 16, 2013 at 10:39 PM, Walter Underwood wrote:
> Do you really want the time that Solr first saw it or do you want the time
> that the document was really created in the system? I
Do you really want the time that Solr first saw it or do you want the time that
the document was really created in the system? I think an external create
timestamp would be a lot more useful.
wunder
On Feb 16, 2013, at 12:37 PM, Isaac Hebsh wrote:
> I opened a JIRA for this improvement request
I opened a JIRA for this improvement 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.
>
10 matches
Mail list logo
