Thomas Hallgren wrote:
[...]
>> If the server makes changes that are not backwards-compatible, of
>> course old drivers are going to break. But a) those sort of changes
>> are rare and b) the same argument holds true for *everything* in the
>> driver.
>
> In this case, the server will implement something that wasn't there
> before so there will not be any compatibility breakage. But since the
> JDBC driver use CallableStatement for something that it wasn't intended
> for, the special mapping it performs will become a problem now that the
> real thing exists.
This is the whole point of using the standard escape syntax: when the
server syntax changes, we can handle it without client applications
needing to change.
Witness support for setFetchSize() evolving through "do nothing" through
"use DECLARE CURSOR and FETCH" through "use V3 portals". And probably
into "(DECLARE CURSOR WITH HOLD and V3 portals) or V4 portals" eventually.
At any rate, {?=call} support is existing functionality that people are
using. Removing support for it because you fear that future code that
hasn't been written yet will break it seems like a bad idea.
As I understand it, the approach being taken for "real" SPs currently is
to extend function behaviour to support the extra bits like OUT
parameters and returned resultsets, probably via extra SQL commands. So
mapping a subset of {call} to what existing functions *do* support seems
fine; we just tweak that mapping to reflect any new features on the
server side. There doesn't seem to be a big model change in the works,
which is all I'd be concerned about. Am I wrong here?
If you have some particular concerns about how the proposed SP syntax,
whatever it is, is going to break the JDBC driver, by all means raise
them.. but this seems like vague handwaving at the moment.
-O
