Strategies

The JDBC river plugin can be configured for different methods of data transport. Such methods of data transports are called a 'strategy'.

Be default, the JDBC River implements a oneshot strategy.

Simple strategy

This strategy contains the following steps of processing:

1. fetch data from the JDBC connection
2. build structured objects and move them to Elasticsearch for creation, indexing, or deleting
3. wait for a certain time before proceeding with step 1

The simple strategy can be refined.

• the sql command which is executed to fetch the data

• the poll time value can be adjusted to the interval how often data should be fetched.

• a digest can be added in order to detect different data transports. If the data of the previous run differs from the current, a housekeeper task is run to detect stale objects that must be deleted from the Elasticsearch index

• versioning can be added to refuse data from the source which is older than the current Elasticsearch documents

• a handshake SQL statement can be given in order to delete the fetched documents. The current documents can be marked with a _job column.

One-shot strategy

The oneshot strategy is like the simple strategy, but there is no loop. The poll parameter is ignored. After a single run, the river stops.

Table strategy

The table strategy does not use an sql command. Instead, a whole table is prepared at the database side from which the rows are selected for indexing. The name of the table must be equal to the river name.

The table strategy can be refined:

• bulk responses form Elasticsearch can be acknowledged into another table, for tight coupling. As soon as the bulk response comes in, an SQL update command is triggered to save the state of indexing to the database side. The acknowledge parameter enables this mode. The name of the acknowledge table is the name of the table plus the suffix _ack appended.