On 20-2-2018 15:45, vasiliy.yashkov@... [Firebird-Java] wrote:

> I saw, that in the firebird master implemented a new batch interface -
> commit
> https://github.com/FirebirdSQL/firebird/commit/f53c23c17a8a72972d487fc2b3a5840a0894025f.
>
>
> To what extent does the current driver (master branch) state correspond
> to these changes? If I'm not mistaken, the driver supports batchs via
> the wire. Will there be changes? And will the native implementation of
> the new interface? If there are no plans in the future, then I will try
> to implement it and make PR.

Jaybird currently simulates batches, which works the same as if
executing statements individually. So technically, Jaybird doesn't batch
at the moment, it just fulfills the requirements of the JDBC API.

I wasn't even aware this feature was already in Firebird 4 until last
week. I have skimmed the implementation, and as usual there is no
documentation on the wire protocol, except having to parse the Firebird
source code, and making use of tools like WireShark. And what I have
seen from the gbak changes merged last week, it might still be in flux.

In any case, I would love to have this in Jaybird, but I'm not sure when
I'll get to it. So, PRs are welcome!

Some things to take into consideration:

- The batch API requires wire protocol version 16. I haven't started on
this yet (given the lack of documentation and lack of time/energy).

This means other changes for wire protocol version 16 (and maybe from 14
and 15) need to be taken into account, which might make things more
complicated.

For example, the new timeout feature needs to send additional data in a
statement execute (or maybe prepare?), so as long as I haven't started
on those parts of protocol 16, you'll need to provide this with a
reasonable default (as in: you don't need to implement timeouts, but you
will need to change the protocol sufficiently so Firebird doesn't 'break').

Given the lack of documentation, it might be hard to identify which
protocol 14-16 changes need to be taken into account (some can be safely
ignored).

- There may be a problem/conflict surrounding the existing handling of
CHAR-fields in Jaybird with statement execution: currently on each
execute we communicate the actual char-size, which doesn't seem possible
for the batch API, as those sizes seem to be communicated once.

- The native support in Jaybird uses the old native API, I don't think
this new batch API is surfaced in the old API. It might be better to
skip this for now.

- Because of the support for different protocol versions, and the
complication with the native API, batch execution needs to be moved into
the GDS-ng layer. From the perspective of the JDBC layer execution
should exhibit the same behavior across protocol versions. That is, the
JDBC layer will use a single set of methods or interfaces (etc), while
the GDS-ng layer will either apply the old way of executing statements
individually, or use the new batch handling.

- This new batch API supports sending blobs in-line, this does not mesh
with how blob parameters work currently in Jaybird, so it is probably
better to leave that for now and instead register the existing blobs as
created by Jaybird, and defer in-line blobs for a future change (it may
then even make sense to use the new batch API for single executions).

- I'm not sure how the new API handles INSERT .. RETURNING, but it needs
to be supported in some way (if necessary, fallback to old-style execution)

Because I'm considering releasing Jaybird under a different open source
license than LGPL in the future, you will also need to fill in and sign
the Contributor License Agreement (either digitally using PGP/GPG, or
signing it on paper and sending me the scanned/photographed version),
see
https://github.com/FirebirdSQL/jaybird/blob/master/licenses/jaybird-icla.txt

Let me know if you're interested in doing this, and keep me in the loop.

Mark
--
Mark Rotteveel