Must Mention here. This Atomic Update will only work if you all your fields
are stored.  It eases out work on your part, but the stored fields will
bloat the index.





On 12 July 2014 22:06, Erick Erickson <erickerick...@gmail.com> wrote:

> bq: But does performance remain same in this situation
>
> No. Some documents will require two calls to be indexed. And you'll
> be sending one document at a time rather than batching them up.
> Of course it'll be slower. But will it still be "fast enough"? Only you can
> answer that.....
>
> If it's _really_ a problem, you could consider using a custom update
> processor
> plugin that does all this on the server side. This would not require you to
> change Solr code, just write a relatively small bit of code and use the
> plugin infrastructure.
>
> Best,
> Erick
>
> On Thu, Jul 10, 2014 at 1:56 PM, Ali Nazemian <alinazem...@gmail.com>
> wrote:
> > Thank you very much. Now I understand what was the idea. It is better
> than
> > changing Solr. But does performance remain same in this situation?
> >
> >
> > On Tue, Jul 8, 2014 at 10:43 PM, Chris Hostetter <
> hossman_luc...@fucit.org>
> > wrote:
> >
> >>
> >> I think you are missunderstanding what Himanshu is suggesting to you.
> >>
> >> You don't need to make lots of big changes ot the internals of solr's
> code
> >> to get what you want -- instead you can leverage the Atomic Updates &
> >> Optimistic Concurrency features of Solr to get the existing internal
> Solr
> >> to reject any attempts to add a duplicate documentunless the client code
> >> sending the document specifies it should be an "update".
> >>
> >> This means your client code needs to be a bit more sophisticated, but
> the
> >> benefit is that you don't have to try to make complex changes to the
> >> internals of Solr that may be impossible and/or difficult to
> >> support/upgrade later.
> >>
> >> More details...
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents#UpdatingPartsofDocuments-OptimisticConcurrency
> >>
> >> Simplest possible idea based on the basic info you have given so far...
> >>
> >> 1) send every doc using _version_=-1
> >> 2a) if doc update fails with error 409, that means a version of this doc
> >> already exists
> >> 2b) resend just the field changes (using "set" atomic
> >> operation) and specify _version_=1
> >>
> >>
> >>
> >> : Dear Himanshu,
> >> : Hi,
> >> : You misunderstood what I meant. I am not going to update some field.
> I am
> >> : going to change what Solr do on duplication of uniquekey field. I dont
> >> want
> >> : to solr overwrite Whole document I just want to overwrite some parts
> of
> >> : document. This situation does not come from user side this is what
> solr
> >> do
> >> : to documents with duplicated uniquekey.
> >> : Regards.
> >> :
> >> :
> >> : On Tue, Jul 8, 2014 at 12:29 PM, Himanshu Mehrotra <
> >> : himanshu.mehro...@snapdeal.com> wrote:
> >> :
> >> : > Please look at https://wiki.apache.org/solr/Atomic_Updates
> >> : >
> >> : > This does what you want just update relevant fields.
> >> : >
> >> : > Thanks,
> >> : > Himanshu
> >> : >
> >> : >
> >> : > On Tue, Jul 8, 2014 at 1:09 PM, Ali Nazemian <alinazem...@gmail.com
> >
> >> : > wrote:
> >> : >
> >> : > > Dears,
> >> : > > Hi,
> >> : > > According to my requirement I need to change the default behavior
> of
> >> Solr
> >> : > > for overwriting the whole document on unique-key duplication. I am
> >> going
> >> : > to
> >> : > > change that the overwrite just part of document (some fields) and
> >> other
> >> : > > parts of document (other fields) remain unchanged. First of all I
> >> need to
> >> : > > know such changing in Solr behavior is possible? Second, I really
> >> : > > appreciate if you can guide me through what class/classes should I
> >> : > consider
> >> : > > for changing that?
> >> : > > Best regards.
> >> : > >
> >> : > > --
> >> : > > A.Nazemian
> >> : > >
> >> : >
> >> :
> >> :
> >> :
> >> : --
> >> : A.Nazemian
> >> :
> >>
> >> -Hoss
> >> http://www.lucidworks.com/
> >>
> >
> >
> >
> > --
> > A.Nazemian
>



-- 
---
Thanks & Regards
Umesh Prasad

Reply via email to