cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Durrant, Peter" <Peter.Durr...@COGNOS.com>
Subject RE: ESQL Extension
Date Wed, 09 Jan 2002 17:21:52 GMT
>> The (brief) details of the changes are:
>> 	(1) addition of CallableStatement to the EsqlQuery class and
>> corresponding import
>
> The problem I see here is that you'd need to cater for SPs that don't
> have "out" parameters. So perhaps <call/> instead of <query/> could be
> used to distinguish.

My implementation allows the user to optionally specify an output parameter.
At the moment if an output parameter is specified, it assumes that it's the
first parameter - the getObject method is currently hardcoded to 1. It also
assumes that it is either a ResultSet or derived from ResultSet since the
returned object from getObject is cast to ResultSet. It also assumes that
you have 0 or 1 output parameters. 0 output parameters are OK for SQL Server
etc. which return a resultSet if the stored procedure is a query.

Obviously more work could be done here -- I'll keep working on it if people
are happy with what I've done so far. I'll attempt a diff and post that
asap.


> see above. I'd rather not use a tag after spec'ing the query / call to
> do the right thing(tm).

I agree. I didn't change query to call or anything else because I wanted to
keep the code changes to a minimum - changing query to something else would
have been a much larger task. I wonder if there's a smart way to deal with
this? For example, esql currently distinguishes between queries and prepared
statements automically just through the presence of parameters in the query.
I wanted to do something similiar but there wasn't an identifiable
difference between prepared statements and stored procedures in terms of
syntax (well in terms of esql tags really).

However bigger changes might be needed if we're to handle other return types
with stored procedures. 

Pete
--
Cognos, London, UK

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender by
e-mail promptly that you have done so.  Thank You.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message