On 05/01/16 15:35, Vladimir Sitnikov wrote:
>> So rather than asking everybody to add new messages to the protocol to support this, wouldn't it be better to
supportLD in the driver?
> Well, it would still require to wrap one's mind around to get that efficient.
> You do not like to deallocate all server-prepared statements after
> each DDL, do you?
> On the other hand, JDBC driver does not know changes to which
> tables/views/functions/types would impact statements prepared in
> current session, thus JDBC driver has no idea which changes it should
> subscribe to.
That's a tough question whether to drop or re-create prepared
statements if they point to database objects that have been modified.
Needless to say, the naive approach is to drop them all and re-create
them when required. Any more clever algorithm than this one would be an
improvements.
However, I still fail to see how this is related to how to acquire
the knowledge of schema changes. Whether you get it via v4 protocol
messages or LD, either way, you have the same problem with the prepared
statements. And, in any case, if schema changes were to be implemented
as part of the protocol, it would surely be push messages sent
asynchronously. Not that different from consuming LD.
My point is that I envision strong opposition to add duplicate
functionality. If schema changes could be obtained from LD, I presume
there will be opposition to *also* add it to the protocol just because
it may not be a great fit for the JDBC driver.
>
>> wouldn't it be better to support LD in the driver?
> That's another question. +1 for supporting LD in the driver (for both
> internal and external uses).
Nice, me too :)
Álvaro
--
Álvaro Hernández Tortosa
-----------
8Kdata