lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Prentice <s...@leximation.com>
Subject Re: BUMP: Atomic updates and POST command?
Date Sat, 01 Sep 2018 00:15:03 GMT
Hmm. That makes sense .. but where do you provide the endpoint to post? 
Is that additional commands within the JSON or a parameter at the 
command line?

Thanks,
...scott


On 8/31/18 4:48 PM, Alexandre Rafalovitch wrote:
> 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 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
>>>
>>>
>>>
>>>
>>>
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message