I think you are using different end points there. /update by default vs
/update/json

So i think the post gets treated as generic json parsing.

Can you try the same end point?

Regards,
     Alex


On Fri, Aug 31, 2018, 7:05 PM Scott Prentice, <s...@leximation.com> wrote:

> Just bumping this post from a few days ago.
>
> Is anyone using atomic updates? If so, how are you passing the updates
> to Solr? I'm seeing a significant difference between the REST API and
> the post command .. is this to be expected? What's the recommended
> method for doing the update?
>
> Thanks!
> ...scott
>
>
> On 8/29/18 3:02 PM, Scott Prentice wrote:
> > Hi...
> >
> > I'm trying to get atomic updates working and am seeing some
> > strangeness. Here's my JSON with the data to update ..
> >
> > [{"id":"/unique/path/id",
> >   "field1":{"set","newvalue1"},
> >   "field2":{"set","newvalue2"}
> > }]
> >
> > If I use the REST API via curl it works fine. With the following
> > command, the field1 and field2 fields get the new values, and all's well.
> >
> > curl 'http://localhost:8983/solr/core01/update/json?commit=true'
> > --data-binary @test1.json -H 'Content-type:application/json'
> >
> > BUT, if I use the post command ..
> >
> > ./bin/post -c core01 /home/xtech/solrtest/test1.json
> >
> > .. the record gets updated with new fields named "field1.set" and
> > "field2.set", and the managed-schema file is modified to include these
> > new field definitions. Not at all what I'd expect or want. Is there
> > some setting or switch that will let the post command work "properly",
> > or am I misunderstanding what's correct? I can use curl, but our
> > current workflow uses the post command so I thought that might do the
> > job.
> >
> > Any thoughts are welcome!
> >
> > Thanks,
> > ...scott
> >
> >
> >
> >
> >
>
>

Reply via email to