Fail fast if query has multiple statements

[chadlwilson]

Context / Goal

Technically the current implementation probably allows multiple statements to be expressed inside the queries, and will be executed.

This shouldn't be allowed and should ideally fail at execution, however as noted in #56, we don't actually have capacity to do SQL parsing - this is delegated to the database and/or drivers.

Expected Outcome

• Test what happens if you put multiple statements in a query, separated by ;
• Ideally it will fail, however I think the code at https://github.com/chadlwilson/recce/blob/30713924d67196f65457ae4098c85cb3c3fdf143/src/main/kotlin/recce/server/dataset/DataLoadDefinition.kt#L24-L28 producing Flux<Result> might mean it blindly tries to continue and produces weird output.
• it might be as simple as changing the definition to add .singleOrEmpty() or .toMono() but I'm not sure what the difference is between these two approaches and haven't tried it

Out of Scope

Additional context / implementation notes

[jiawen-tw]

• Observed that the number of sql statements corresponds to the number of elements in Flux

• Before proceeding with hashing and saving, checked the number of elements in Flux to be exactly one, else an exception is thrown

• For the current implementation, if there is error with target query, it will only be triggered after source has finished saving as target is only loaded after source is completed

• Fix DatasetRecServiceTest tests for reconciliation of empty source and/or target to mock zero rows in result; it was previously mocking zero results which implied no sql query was configured

• For stylistic consideration: For tests, use Kotlin extensions provided by Reactor flux.test().verifyComplete() instead of the Java default one StepVerifier.create(flux).verifyComplete()

[chadlwilson]

• For stylistic consideration: For tests, use Kotlin extensions provided by Reactor flux.test().verifyComplete() instead of the Java default one StepVerifier.create(flux).verifyComplete()

@jiawen-tw Cool, didn't know that existed!

[chadlwilson]

Had to revert and re-open this as the earlier solution seemed to be interfering with the batching and breaking the reactive chain somehow. Current theory is that it has exposed that we are missing a unit test that ensures things work when there are batches in place.

If not strictly due to the batching, the switch to doOnNext -> single -> flatMapMany seems to cause issues.

Observed behaviour is that even with a single query, the reactive chain just dies/disappears with no feedback to the user. The HTTP request just blocks.

This can be tested manually using the big-table-postgres scenario.