Ah .. is this done with the -url parameter? As in ..
./bin/post -url http://localhost:8983/solr/core01/update/json
/home/xtech/solrtest/test1.json
Will test.
Thanks,
...scott
On 8/31/18 5:15 PM, Scott Prentice wrote:
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
