[BUG] Bulk UpdateOperation misses upsert options

[fs-chris]

What is the bug?

The UpdateOperation only supports setting a document.
There are no options for defining upserts like script, (scripted-)upsert, docAsUpsert etc. as in the common org.opensearch.client.opensearch.core.UpdateRequest
In Elasticsearch these settings are done for bulks via UpdateAction which can be set into the UpdateOperation.

How can one reproduce the bug?

n/a

What is the expected behavior?

Bulk UpdateOperations should support all update/upsert options as in org.opensearch.client.opensearch.core.UpdateRequest

What is your host/environment?

Windows and Linux, Java 17
OpenSearch server 2.4.0
OpenSearch client 2.1.0

Do you have any screenshots?

n/a

Do you have any additional context?

[wbeckler]

This makes sense. Are you up for a PR for this?

[fs-chris]

I'm sorry, but because of the number and severity of bugs in the current version of this client I had to switch to the HLRC which appears to be more mature.
And unfortunately we currently don't have capacity to participate and provide a fix.

[assafcoh]

Hi guys, this capability is basic and important.
Any time estimations for adding this?

[wbeckler]

Nothing is scheduled for this issue but it sounds like a blocker to deprecating the hlrc.

@fs-chris what other issues were driving you away from OpenSearch-java?

[fs-chris]

Besides this one, there is another show-stopper for me: support of sub-aggregations #197

Other, less significant yet annoying issues are

• Missing BulkProcessor [FEATURE] Reimplement BulkProcessor #181
• Creating (partial-) requests from raw JSON [FEATURE] Raw Json support #257
• Support otherSettings() in IndexSettings (et al.) for handling settings currently missing in the API

To be fair, the Elasticsearch version of this client also has lots of problems which mainly originate in a wrong or incomplete data model, which often leads to missing-required-property exception that prevents getting responses for certain requests.

With OpenSearch-client, I didn't reach the point where I would trap into similar issues, since they occur at execution time only.

[dblock]

@fs-chris We're working towards #284 to permanently solve the missing/incomplete APIs problems. Any help appreciated.

[wbeckler]

@fs-chris in terms of #197 there's a fix merged in main that will go out with the next release, so subaggregations should work if you're willing to work with the unreleased client. It would be great if you wanted to try it out.

[fs-chris]

I appreciate all work done to improve this client.
However, for now I have to struggle with HLRC to get it into our product.
I will certainly test this new client again as soon as new versions are released and the major issues are fixed.

[assafcoh]

Hi guys,
We tried the new 2.2.0 version, but noticed updating with a Script is still not supported.
This is a very basic functionality, and blocks us from using the opensearch java client :(

For example we would like to create an opensearch Script object, and use it like below:

new BulkOperation.Builder()
      .update(new UpdateOperation.Builder<DataInfo>()
              .index("my-index")
              .id("doc-123")
              .script(myScriptObj)
              .upsert(dataInfo)
              .build())
      .build()

our team would greatly appreciate your estimation regarding supporting this.

[dblock]

@assafcoh Try contributing this feature? What help do you need?

[assafcoh]

unfortunately we currently don't have capacity to contribute.
This feature is a basic functionality, and is currently a blocker for us, so I guess we will have to switch to HLRC until this is supported. We will be glad to test this client as soon as this feature is supported.

[reta]

@dblock I think I could help here and look into the issue

[paniavula]

Any thoughts on which release and timeline this is targeted for?

[dblock]

Any thoughts on which release and timeline this is targeted for?

Next release.

@wbeckler When do you want to release next?

[wbeckler]

I think any maintainer can trigger a release and we have not decided on a set schedule for releases. @paniavula what are the implications for you in terms of the timing of the next release?

[paniavula]

I think any maintainer can trigger a release and we have not decided on a set schedule for releases. @paniavula what are the implications for you in terms of the timing of the next release?

This is a blocker for us and cannot switch to using this library as it is a core need in our current version. A more frequent monthly release schedule may also help to boost some confidence.

[reta]

@VachaShah I think nothing is stopping us from making the release, wdyt? (number of important fixes are in)

[VachaShah]

@VachaShah I think nothing is stopping us from making the release, wdyt? (number of important fixes are in)

Yeah nothing is blocking, we can do the next release. I will wait for some fixes that are already in PRs to go in so we can release them as well.

[VachaShah]

@VachaShah I think nothing is stopping us from making the release, wdyt? (number of important fixes are in)

Yeah nothing is blocking, we can do the next release. I will wait for some fixes that are already in PRs to go in so we can release them as well.

Tracking the release in #380 :)