execute(...) should be extended with returning generated keys

[SzalkaiGabor]

Now it is not possible to create a one-to-one relationship with the execute statement, as if you do like this (see below), the flatMap won't be invoked.

databaseClient.execute("INSERT INTO table_a (something) VALUES (:something)")
                .bind("something", "id")
                .fetch().first()
                .flatMap {
                    databaseClient.execute("INSERT INTO table_b (something, table_a_id) VALUES (:something, :table_a_id)")
                            .bind("something", entry.parameters)
                            .bind("table_a_id", it["id"].toString().toLong())
                            .fetch().rowsUpdated()
                }
                .then()

Possible solutions (@mp911de):

We could either accept a Statement customizer or expose returnGeneratedKeys(…).

[mp911de]

This ticket is related to #46 as we want to introduce general customization hooks, similar to WebClient ExchangeFilterFunctions

[Camsteack]

Are there any update on that ? As at the moment it's impossible do things like upsert and get the generated id.

[mp911de]

After investigating on this topic, we do not have proper use-cases for the related ticket #46. Therefore, we're going to introduce a slim version of filter functions for Statement objects. The simple (UnaryOperator) code would look like:

DatabaseClient databaseClient = …;
databaseClient.execute("SELECT")
		.filter(s -> s.returnGeneratedValues("foo"))

the bit more extended approach with a StatementFilterFunction would accept also an ExecuteFunction:

DatabaseClient databaseClient = …;
databaseClient.execute("SELECT")
		.filter((s, next) -> next.execute(s.returnGeneratedValues("foo")))

[schauder]

Done.