[JDBC] Interest in allowing caller to push binary data rather than having it pulled?

Поиск
Список
Период
Сортировка
От Tom Dunstan
Тема [JDBC] Interest in allowing caller to push binary data rather than having it pulled?
Дата
Msg-id C659D6A4-430F-4F55-BE06-BE1C960A5405@tomd.cc
обсуждение исходный текст
Ответы Re: Interest in allowing caller to push binary data ratherthan having it pulled?
Re: Interest in allowing caller to push binary data ratherthan having it pulled?
Список pgsql-jdbc
Hi all

I hit an interesting case today. It’s a bit of a limitation in the JDBC interface, so any support would have to be a
proprietaryinterface. 

Basically I have one or more byte buffers that I’d like to stream into a BYTEA at the server (using a plain INSERT
statement).In my case I’ve got Netty ByteBuf objects, but it could be anything. 

What are my current options? JDBC basically gives me PreparedStatement.setBytes() and
PreparedStatement.setBinaryStream().

PreparedStatement.setBytes() involves copying all the data, potentially multiple large buffers, into a large buffer of
exactlythe correct size. The reason to use ByteBufs in the first place was to pool our use of large buffers so that we
don’tblow out our heap - this completely kills any hope of that. 

PreparedStatement.setBinaryStream() is more flexible, but under the hood we’re just pulling stuff into an intermediary
8kbuffer and then writing it out to the socket. This is OK from a heap management perspective, but still has some
unnecessarycopying. 

What I’d really like to do would be to provide an object that the driver could interrogate for a length and then
providean OutputStream to write to. The interface would look something like: 

interface ByteStreamWriter {
    int getLength();
    void writeTo(OutputStream stream);
}

The provided output stream would be a very thin wrapper around the socket output stream just ensuring that we don’t
writetoo many bytes out. 

Usage would look thusly:

myPreparedStatement.setObject(n, new MyByteStreamWriter(myByteBuf), Types.VARBINARY);

And the user could write whatever adapter they wanted around their data.

There’s an existing StreamWrapper class in the codebase, but it just provides an InputStream when asked. It could be
adjustedto use the above interface for consistency though. 

Thoughts? I’d be happy to code up a PR if there’s interest.

Cheers

Tom




В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Konstantinos Kougios
Дата:
Сообщение: Re: [JDBC] 42.0.0.jre7, driver logging takes 30-40% of my server'stime
Следующее
От: Dave Cramer
Дата:
Сообщение: [JDBC] [pgjdbc/pgjdbc] b97ad6: Honour setLogStream. If the logStream is set(#780...