Sounds great. My main concern is that you change to the return data
will break
most implementations in use today, the same goes with query and pquery
although
adding a cquery would work just fine. One advantage of query is that
it uses a
Statement instead of a Prepared Statement. In MSSQL and other DB's
there is
a hugh performance hit with a Prepared Statement.
Since an SQLDocument really represents an SQL ResultSet why don't you
allow
the XConnection to return multiple SQLDocuments that way query/pquery/cquery
will return the first Result Set then may add a function, getNextResultSet
to grab the
others. That way you support multiple Result Sets without breaking
previous
implementations, also I think it will be less complicated with streaming
mode.
How do you transition from one result set to another in streaming mode
?
I am confused about the use of I/O parameters since most of the SQL
Extension
parameters can be passed either XSL variables or elements and allow
any return
type unless you are modifying parameters that are passed in which probably
violates the XSLT spec.
I personally would not vote in favor of changing the SQL Document return
format
(in a way that breaks previous code) since it would affect 100's
of my existing SS's.
Why don't you post the some example XSL code to the list so we can review
it
and decide on how to integrate the new code. Have you tested both Streaming
and
Non Streaming mode with the new code ??
If you send me a zip file of the code, I will review the implementation.
Regards
John G
[EMAIL PROTECTED] wrote:
I have been working on an enhanced SQL extension for Xalan-J. This adds support for callable statements, multiple result sets, and output parameters. To do this it makes some changes from the syntax of the existing SQL extension. Most significantly to support multiple result sets, the metadata element is made a child of the row-set element. There are also changes to the call syntax. Parameters (input and output) are passed via variables.
I would like to contribute this enhanced SQL to the Xalan project. Is there interest in this contribution? Since this changes the sql extension syntax, should I package this as an alternative function, cquery() for example, or just replace query() and pquery() with a new query()? Note that the new function and be used to do everything that query() and pquery() currently do (with different syntax) as well as the new functionality. In short, if the query has parameter definitions then they are used, if it starts with "CALL" (perhaps after a return parameter definition) then it is assumed to be a CallableStatement.
The current status of this is that it has had only limited testing - but seems to be working. There are some details that need to be cleaned up, some debugging stuff to be deleted, etc. This could be submitted fairly soon (unless further testing uncovers something).
Thank You,
Art
--
--------------------------------------
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
