Art,
The SQL extension is not my baby, it belongs to the whole community.
I just happen to be the first point of contact in managing it. I am also not
resistant to change, even if breaks existing interfaces, as long as there is
a clear rational that the change will add value and is worth the effort.
I think in general, handling callable statements and multiple result sets will
be a welcome addition to the code. As for the other changes, if you could
make a case for what they may fix that was broken before, or what functionality
they add and how it makes the existing code better, I would be willing to put it
up for a vote. I tried to address some of the issues I saw with the code in my
previous response, I am interested in what you don't agree in.
To address the other issues of OUT and INOUT parameters. I suggest that we
keep with the design same pattern (the same one that was abstracted from the
JDBC drivers) and add methods such as addOutputParameterWithType()...
This action could create a HashMap (is Xalan allowed to use JAVA2 object
yet ??) holding the name / value. The in cquery, using those parameters as a
mechanism for the registerOutputParameter JDBC calls.
I would stay away from parsing items out of the Query String such as the OUT
keyword because you can't regulate what someone will call their SP. As silly as
it may sound, what if I wanted to call the SP "OUT", it would probably kill your
parse routine. Same with the [name=type] since SQL calls to an Access DB
sometimes require the [ ] be place around the column name. I can't tell you how
many times I have been called in to support a DB that was hack together with
column names that include spaces and quotes. :-(
As for building up ResultSets to house the output parameters, that sounds like
it may be the long way around. Why not sub class SQLDocument and override
the constructor, extractSQLMetaData, addRowToDTMFromResultSet.
In the constructor, add the HashMap that will be used to pull the output parameters
from the last of the result set.
In extractSQLMetaData & addRowToDTMFromResultSet, use the HashMap as
a pseudo ResultSet.
On a side note, adding a function to XConnection to get the next result set may
have a design caveat. The XConnection can be used to produce more than one
query. Its probably the odd case where the XSL designer notices that 2 XConnections
would give you separate contexts.
If you perform a query that has multiple results sets then while processing that query,
perform another query your unprocessed result sets will probably be lost. To fix this,
we could move the getNextResultSet() to the SQLDocument itself since it always
maintains the current query context. The notion would be that SQLDocuments are
chained.
You never did answer my previous question. Can you concurrently process result
sets on a multi result set query without loosing the context ??
Thank you for all the effort you are putting into the SQL Extensions.
Regards
John G
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
