You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by David Kavanagh <da...@dotech.com> on 2003/05/22 19:09:41 UTC
passing out params
Has anyone used the SQLTransformer to call a sequence of stored
procedures that return out params, where one requires on the outparam of
the previous?
If so, how is it done?
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: passing out params
Posted by David Kavanagh <da...@dotech.com>.
My issue is that some people who have influence of the architecture want
less intelligence in the stored procedures and more in the java (or
cocoon) layer. Therefore, I get to call a series of dumb procedures..
yeah :-/
David
Luca Morandini wrote:
> David Kavanagh wrote:
>
>> I was afraid of that. I'd like to issues a bunch of statements as
>> part of a transaction, so I can rollback if something fails. That
>> isn't possible when I used multiple SQLTransformer instances in a
>> pipeline. Another thing is that I wanted to have one .xsl file that
>> generates the list of statements to be executed in the transaction.
>> That way, I can read the whole transaction very easily. Much nicer to
>> code/debug this way. It gets kind of un-wieldy when I have to split
>> things up to much. I've been avoiding it, but I think I'll just have
>> to write my own action to implement the JDBC calls. sigh.
>>
>
> Well, my standard approach when it comes to transactions is the use of
> Stored Procedures... or triggers maybe.
>
> If you need to call some SPs in sequence, better to put these calls
> inside another SP and call the latter from you pipeline.
>
> Regards,
>
> ------------------------------------------
> Luca Morandini
> GIS Consultant
> lmorandini@ieee.org
> http://space.virgilio.it/kumora/index.html
> ------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: passing out params
Posted by Luca Morandini <lu...@tin.it>.
David Kavanagh wrote:
> I was afraid of that. I'd like to issues a bunch of statements as part
> of a transaction, so I can rollback if something fails. That isn't
> possible when I used multiple SQLTransformer instances in a pipeline.
> Another thing is that I wanted to have one .xsl file that generates the
> list of statements to be executed in the transaction. That way, I can
> read the whole transaction very easily. Much nicer to code/debug this
> way. It gets kind of un-wieldy when I have to split things up to much.
> I've been avoiding it, but I think I'll just have to write my own action
> to implement the JDBC calls. sigh.
>
Well, my standard approach when it comes to transactions is the use of
Stored Procedures... or triggers maybe.
If you need to call some SPs in sequence, better to put these calls
inside another SP and call the latter from you pipeline.
Regards,
------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://space.virgilio.it/kumora/index.html
------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: passing out params
Posted by David Kavanagh <da...@dotech.com>.
I was afraid of that. I'd like to issues a bunch of statements as part
of a transaction, so I can rollback if something fails. That isn't
possible when I used multiple SQLTransformer instances in a pipeline.
Another thing is that I wanted to have one .xsl file that generates the
list of statements to be executed in the transaction. That way, I can
read the whole transaction very easily. Much nicer to code/debug this
way. It gets kind of un-wieldy when I have to split things up to much.
I've been avoiding it, but I think I'll just have to write my own action
to implement the JDBC calls. sigh.
David
Luca Morandini wrote:
> David Kavanagh wrote:
>
>> Has anyone used the SQLTransformer to call a sequence of stored
>> procedures that return out params, where one requires on the outparam
>> of the previous?
>>
>
> I think the only way to do this is by issuing a string of
> sql-transform steps (one feeding the other)... not terribly fast I'm
> afraid.
>
> Regards,
>
> ------------------------------------------
> Luca Morandini
> GIS Consultant
> lmorandini@ieee.org
> http://space.virgilio.it/kumora/index.html
> ------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: passing out params
Posted by Luca Morandini <lu...@tin.it>.
David Kavanagh wrote:
> Has anyone used the SQLTransformer to call a sequence of stored
> procedures that return out params, where one requires on the outparam of
> the previous?
>
I think the only way to do this is by issuing a string of sql-transform
steps (one feeding the other)... not terribly fast I'm afraid.
Regards,
------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://space.virgilio.it/kumora/index.html
------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org