Atomic updates

[GoogleCodeExporter]

http://wiki.apache.org/solr/Atomic_Updates
http://yonik.com/solr/atomic-updates/
http://wiki.apache.org/solr/UpdateXmlMessages#Optional_attributes_for_.22field.2
2

Original issue reported on code.google.com by mauricio...@gmail.com on 13 Nov 2012 at 1:06

[GoogleCodeExporter]

This is a must have feature... 

Original comment by jariwala...@gmail.com on 25 Dec 2012 at 6:55

[GoogleCodeExporter]

+1 from me :-) Atomic updates is one of the really useful new things in Solr 
4.0/4.1

Original comment by stein.g...@coxito.com on 15 Feb 2013 at 8:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

In the interim use the following work around:

1. Build a custom atomic update XML message
2. Get hold of the connection object (via ServiceLocator)
3. Issue a call to Solr via the connection object
Details posted here: 
http://teach-algo.blogspot.in/2013/03/atomic-updates-via-solrnet.html

Original comment by alghos...@gmail.com on 12 Apr 2013 at 4:12

[GoogleCodeExporter]

@alghoshal : nice, it shows how you can use the "inner" components of SolrNet, 
which was always one of my goals. 

I've been thinking a bit about possible ways to implement this "properly". For 
Dictionary<string,object> documents, we could use a similar strategy as I 
explained in https://groups.google.com/d/msg/solrnet/iZlaw7Yn4_U/Nm9WwYqLyNUJ 
for boosted fields.

For typed documents, we could add a property to SolrFieldAttribute that 
indicates the modifier to apply. E.g.:

class Document {
    [SolrField("some_field", Update = Update.Set)]
    public string SomeField {get;set;}

    [SolrField("some_other_field", Update = Update.Add)]
    public ICollection<string> SomeOtherField {get;set;}
}

Of course, this would require that the user either maps a new type for "atomic" 
(I really dislike this term in this context) update operations, or has specific 
properties for updates that otherwise have to remain with null values.
And as usual, since properties aren't first-class values, you can't decide what 
to update or not at runtime (but you can with a Dictionary<string, object> at 
the expense of proper typing).

Thoughts?

Original comment by mauricio...@gmail.com on 12 Apr 2013 at 9:50

[GoogleCodeExporter]

What about some sort of of interceptor after SolrNet finished the mapping? So, 
not null fields all get mapped and then interceptor has a chance to take a 
dictionary and mark each one as Update/Set/Inc? Maybe a visitor that gets a 
field and returns operation on it. Then, Solr translates that into standard set 
or into atomic update operation.

This, of course, looses the mapping transparency as fields are converted to 
names and there is a problem with deleting values (setting to null). But it is 
probably equal-pain solution to additional document type.

Original comment by arafalov@gmail.com on 24 Apr 2013 at 7:02

[GoogleCodeExporter]

@arafalov : I don't understand, could you please illustrate with some 
(pseudo)code?

Original comment by mauricio...@gmail.com on 24 Apr 2013 at 11:56

[GoogleCodeExporter]

Moved to https://github.com/mausch/SolrNet/issues/108

Original comment by mauricio...@gmail.com on 9 Sep 2013 at 8:39