On 05/01/16 17:15, Vladimir Sitnikov wrote:
>> it would surely be push messages sent asynchronously
> Well, full async here could be bad since it would be bad throw
> exceptions like "you are executing queries faster than JDBC driver
> fetches LD queue" at user.
I don't see a problem there neither. First, LD changes will be
consumed as fast as possible, and then the rest of the driver may act
upon schema changes when possible. If consuming that LD falls behind
while user is executing queries like mad, it may happen that a (now
wrong) prepared statement may be called. And it will error. But that's
ok, after all, that's what you will get anyway if executing queries
against a table modified concurrently.
> Otherwise JDBC driver would have hard time figuring out if "all the
> DDL notifications have been generated and consumed".
So as per the above, I won't synchronously wait on that. I will
only update JDBC's meta information when it arrives.
>
> Nevertheless, whatever interface is chosen to signal DDL changes, it
> makes sense to consider "granular notifications" (including per
> "prepared-statement" ones) from the start even if the very first
> implementation would sent just "discard all".
If I understand it correctly, by granular you mean that the
notifications should include enough information to determine which
tables and columns have changed. If this is the case, sure, I think it's
completely necessary, even if, as we have said, we use a discard all
prepared statements in a first implementation.
Álvaro
--
Álvaro Hernández Tortosa
-----------
8Kdata