Support for update API

[mangvlad]

Any way to allow for 'optype' to be 'update'?
This will make it very easy to use several SQL statements for a single document...

[jprante]

Update uses scripting and versioning. Both is quite complicated to support by SQL commands.

Because of update conflicts, the JDBC river would also have to offer additional recovery strategies in the configuration. Although of that, unresolvable conflicts may occur, data may get lost if recovery fails.

And also, each river instance should "behave" and write to his "own" documents. Multiple rivers to a single index with overlapping docs would be encouraged by update support.

But JDBC river should be KISS - keep it simple.

I decided against update support for theses reasons.

[mangvlad]

I see... It makes sense, but... :)

Maybe there is a way to allow as an alternative, another strategy - a generic access to the bulk API.

One query should return actions and another one should return source docs (one per row) with both queries required to have the same number of rows and actions query including all/any allowed/required "underscore" fields.

The response can be made available as a parameter for an optional follow up update query...

Just trying to look for ways to match the features ES now provides with what a river can do...

Thanks!

[jprante]

Yes, another strategy with two queries is an option. It would be a little bit confusing to create the doc id in one statement and lose relationship to other fields created by another SQL statement that form the source though. Requirement of same number of rows is not what I would prefer, this is impossible to control.

Note, that even with simple strategy, results from last row are available as parameters for follow-up query. I admit is not (well) documented.