You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2002/07/11 22:44:37 UTC
[PROPOSAL] Remove SQLTransformer in 2.1
Hi All,
Backward compatibility among minor revisions is generally a smart and
good thing to do. However, there does
become a point where it grows six legs and starts biting you.
The ESQL generator AFAIK supports everything one could need to do via
the SQLTransformer and there does not seem
to be a reason to continue to support both technologies.
IMHO, while the code quality of the ESQL stylesheet is relatively low,
the quality of the SQLTransformer is lower probably due to code rot and
negative evolutionary pressures.
I would suppose the SQLTransformer being largely a Cocoon 1.x construct
is reasonable slow and my own unscientific benchmarking seems to confirm
this.
I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
newer releases, remove all SQLTransformer based samples (or provide esql
alternatives).
Thoughts?
-Andy
Tom Klaasen wrote:
> Joshua McCulloch wrote:
>
>> The queries are definitely not taking 130ms outside of
>> cocoon.
>>
>
> Can you put numbers on this? How much does it take to do the same
> queries in a simple java program? (setup connections, start timer,
> execute queries, stop timer)
>
> And on another note: does it also takes 130 ms if the SQLTransformer
> is already executed some times? The first time, you have overhead in
> creating connections etc, while after some times, the connections are
> taken from a pool.
>
>>
>> What do you mean by turning off debugging? I've
>> changed the logging status to ERROR, and saw some
>> improvement. What did you turn off, and how did you do
>> so?
>>
>
> That's what I meant: change logging status to ERROR. I'm not sure
> though if this can still be done on one place, or if there are more
> places nowadays where you can reduce the logging level (yeah, I know,
> my in-depth days of Cocoon are some time behind me already. I hope I
> can get to work on some Cocoon project again, but that won't be in the
> near future).
>
>> Thanks! :)
>>
>
> np, that's what we're here for ;)
>
> tomK
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Here is one...
>
>xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
>
>If this idea picks up, SQLTransformer will be re-implemented as a set of
>tags (one tag?), and ESQL will be deprecated.
>
>:)
>
>
>PS SQLTransformer code might be messy. But functionality it provides is
>valuable to some (many?) users.
>
>Vadim
>
>
Looks like this:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoon/components/elementprocessor/
Personally I don't like the concept of generating XML at the transformer
level.
Can you give a use case where it is necessary?
-Andy
>
>
>>-Andy
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> Bertrand Delacretaz wrote:
>
> >On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
> >
> >>. . .
> >>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> >>newer releases, remove all SQLTransformer based samples (or provide
esql
> >>alternatives).
> >>
> >
> >(I have no formal voting rights here but)
> >-1
> >
> >Why remove a component that works?
> >This would certainly break some existing apps and annoy users.
> >
> >Maybe it could be marked "deprecated", as is done in java, meaning it
won't
> >be developed any further and is not recommended for new projects.
> >
> And that has worked so well in Java.... hehe. Its been deprecated for
> awhile. The documentation has said this. Officially
> Sun considers deprecated to mean that in future releases it may go
away.
> They're just lazy about doing it. This results in
> some things that work intermittantly which is the worst kind of bug.
>
> One reason is that its a maintenance drag, cocoon is undergoing some
> resonable re-engineering under the covers, along with Avalon.
Updating
> this deprecated class is a drag.
>
> As an alternative, perhaps we could move it off into something like
the
> scratchpad like a "oldstuff" or "compatibility-layer" kinda deal so
that
> it isn't included by default.
>
> Thoughts?
Here is one...
xml-cocoon2\src\scratchpad\src\org\apache\cocoon\taglib\Tag.java
If this idea picks up, SQLTransformer will be re-implemented as a set of
tags (one tag?), and ESQL will be deprecated.
:)
PS SQLTransformer code might be messy. But functionality it provides is
valuable to some (many?) users.
Vadim
> -Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> ESQL is certainly more developed, but it is not a replacement. Where
> in SQLTransformer do you suspect code rot? Have people been
> experiencing problems with it?
Open up the sourceode for the transformer, look at the amount of
repetitive code.. . The SQL Transformer is also some many factors slower
than ESQL. There is no shared source between them so fixes to each have
to be done seperately. For instance I needed support for big numbers, I
had to work in both places for consistancy.
-Andy
>
> --Greg Weinger
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Greg Weinger <gw...@itmedicine.net>.
Per Kreipke wrote:
>>The ESQL generator AFAIK supports everything one could need to do via
>>the SQLTransformer and there does not seem
>>to be a reason to continue to support both technologies.
>>
>>
>
>How can that be true? The transformation point in the pipeline is very
>different than a generator. For example, I can order transformations such
>that the SQL transformer comes between other transforms but you couldn't do
>that with a generator.
>
>Per
>
>
I have to second this; I have long disagreed with the implication, in
the documentation, that the SQLTransformer should be deprecated because
of ESQL.
It gives new users the sense that the Generation stage is the only place
to perform "heavy-duty" operations like data access. I think this
discourages creative thinking in using the Transformation stage to solve
problems. Just because M-V (of MVC fame) maps nicely to G-T, doesn't
mean that it should in every case, or that this is necessarily
preferable. A well-crafted Transformer can provide extremely effective
code reuse.
ESQL is certainly more developed, but it is not a replacement. Where in
SQLTransformer do you suspect code rot? Have people been experiencing
problems with it?
--Greg Weinger
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>How can that be true? The transformation point in the pipeline is very
>different than a generator. For example, I can order transformations such
>that the SQL transformer comes between other transforms but you couldn't do
>that with a generator.
>
>
Very few times is there a reason to build your query and pass it to the
transformation layer and I sure can't think of one. Secondly, this
"Transformer" is an extreme violation of the contract specified for a
Transformer. It more fits in with what a generator does.
-Andy
>Per
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Per Kreipke <pe...@onclave.com>.
> The ESQL generator AFAIK supports everything one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
How can that be true? The transformation point in the pipeline is very
different than a generator. For example, I can order transformations such
that the SQL transformer comes between other transforms but you couldn't do
that with a generator.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Bertrand Delacretaz wrote:
>On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>
>
>>. . .
>>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>newer releases, remove all SQLTransformer based samples (or provide esql
>>alternatives).
>>
>>
>
>(I have no formal voting rights here but)
>-1
>
>Why remove a component that works?
>This would certainly break some existing apps and annoy users.
>
>Maybe it could be marked "deprecated", as is done in java, meaning it won't
>be developed any further and is not recommended for new projects.
>
>
>
And that has worked so well in Java.... hehe. Its been deprecated for
awhile. The documentation has said this. Officially
Sun considers deprecated to mean that in future releases it may go away.
They're just lazy about doing it. This results in
some things that work intermittantly which is the worst kind of bug.
One reason is that its a maintenance drag, cocoon is undergoing some
resonable re-engineering under the covers, along with Avalon. Updating
this deprecated class is a drag.
As an alternative, perhaps we could move it off into something like the
scratchpad like a "oldstuff" or "compatibility-layer" kinda deal so that
it isn't included by default.
Thoughts?
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 11 July 2002 22:44, Andrew C. Oliver wrote:
>. . .
> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> newer releases, remove all SQLTransformer based samples (or provide esql
> alternatives).
(I have no formal voting rights here but)
-1
Why remove a component that works?
This would certainly break some existing apps and annoy users.
Maybe it could be marked "deprecated", as is done in java, meaning it won't
be developed any further and is not recommended for new projects.
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [DOCUMENTATION ISSUE] Re: [PROPOSAL] Remove SQLTransformer in
2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
My bad...someone already did.
Andrew C. Oliver wrote:
> oh and can we remove the "its deprecated" notation from the
> documentation.
>
> Time permitting, I'll attempt to resolve why it is so slow by comparison.
>
> -Andy
>
> Carsten Ziegeler wrote:
>
>> Andrew C. Oliver wrote:
>>
>>
>>> Hi All,
>>>
>>> Backward compatibility among minor revisions is generally a smart
>>> and good thing to do. However, there does
>>> become a point where it grows six legs and starts biting you.
>>>
>>> The ESQL generator AFAIK supports everything one could need to do
>>> via the SQLTransformer and there does not seem
>>> to be a reason to continue to support both technologies.
>>>
>>> IMHO, while the code quality of the ESQL stylesheet is relatively
>>> low, the quality of the SQLTransformer is lower probably due to code
>>> rot and negative evolutionary pressures.
>>>
>>> I would suppose the SQLTransformer being largely a Cocoon 1.x
>>> construct is reasonable slow and my own unscientific benchmarking
>>> seems to confirm this.
>>>
>>> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>> newer releases, remove all SQLTransformer based samples (or provide
>>> esql alternatives).
>>>
>>>
>>
>> -10
>>
>> The SQLTransformer provides a very good alternative to ESQL, it is in
>> some use cases more flexible as it is a transformer and not a generator.
>> And you don't need XSP to use it.
>>
>> The SQLTransformer in its current state is not a 1.x construct, it has
>> been redesigned several times and works afaik absolutely perfect. It
>> is used in production environments without any problems.
>>
>> Carsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[DOCUMENTATION ISSUE] Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
oh and can we remove the "its deprecated" notation from the documentation.
Time permitting, I'll attempt to resolve why it is so slow by comparison.
-Andy
Carsten Ziegeler wrote:
>Andrew C. Oliver wrote:
>
>
>>Hi All,
>>
>>Backward compatibility among minor revisions is generally a smart and
>>good thing to do. However, there does
>>become a point where it grows six legs and starts biting you.
>>
>>The ESQL generator AFAIK supports everything one could need to do via
>>the SQLTransformer and there does not seem
>>to be a reason to continue to support both technologies.
>>
>>IMHO, while the code quality of the ESQL stylesheet is relatively low,
>>the quality of the SQLTransformer is lower probably due to code rot and
>>negative evolutionary pressures.
>>
>>I would suppose the SQLTransformer being largely a Cocoon 1.x construct
>>is reasonable slow and my own unscientific benchmarking seems to confirm
>>this.
>>
>>I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
>>newer releases, remove all SQLTransformer based samples (or provide esql
>>alternatives).
>>
>>
>>
>-10
>
>The SQLTransformer provides a very good alternative to ESQL, it is in
>some use cases more flexible as it is a transformer and not a generator.
>And you don't need XSP to use it.
>
>The SQLTransformer in its current state is not a 1.x construct, it has
>been redesigned several times and works afaik absolutely perfect. It
>is used in production environments without any problems.
>
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>It is remarkably slower than ESQL. Okay if you feel this strongly about
>>it then thats fine. Would you
>>be against refactoring the two and moving the common constructs to
>>common classes as Vadim suggested?
>>
>>
>>
>No, refactoring sounds like a good idea as long as the SQLTransformer
>is not dependend on any XSP stuff.
>
>
I would consider that a given. Great then.
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
> >-10
> >
> >The SQLTransformer provides a very good alternative to ESQL, it is in
> >some use cases more flexible as it is a transformer and not a generator.
> >And you don't need XSP to use it.
> >
> >The SQLTransformer in its current state is not a 1.x construct, it has
> >been redesigned several times and works afaik absolutely perfect. It
> >is used in production environments without any problems.
> >
> >
> It is remarkably slower than ESQL. Okay if you feel this strongly about
> it then thats fine. Would you
> be against refactoring the two and moving the common constructs to
> common classes as Vadim suggested?
>
No, refactoring sounds like a good idea as long as the SQLTransformer
is not dependend on any XSP stuff.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>
>>
>-10
>
>The SQLTransformer provides a very good alternative to ESQL, it is in
>some use cases more flexible as it is a transformer and not a generator.
>And you don't need XSP to use it.
>
>The SQLTransformer in its current state is not a 1.x construct, it has
>been redesigned several times and works afaik absolutely perfect. It
>is used in production environments without any problems.
>
>
It is remarkably slower than ESQL. Okay if you feel this strongly about
it then thats fine. Would you
be against refactoring the two and moving the common constructs to
common classes as Vadim suggested?
-Andy
>Carsten
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [PROPOSAL] Remove SQLTransformer in 2.1
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Andrew C. Oliver wrote:
>
> Hi All,
>
> Backward compatibility among minor revisions is generally a smart and
> good thing to do. However, there does
> become a point where it grows six legs and starts biting you.
>
> The ESQL generator AFAIK supports everything one could need to do via
> the SQLTransformer and there does not seem
> to be a reason to continue to support both technologies.
>
> IMHO, while the code quality of the ESQL stylesheet is relatively low,
> the quality of the SQLTransformer is lower probably due to code rot and
> negative evolutionary pressures.
>
> I would suppose the SQLTransformer being largely a Cocoon 1.x construct
> is reasonable slow and my own unscientific benchmarking seems to confirm
> this.
>
> I'd like to propose we remove the SQLTransformer from Cocoon 2.1 and
> newer releases, remove all SQLTransformer based samples (or provide esql
> alternatives).
>
-10
The SQLTransformer provides a very good alternative to ESQL, it is in
some use cases more flexible as it is a transformer and not a generator.
And you don't need XSP to use it.
The SQLTransformer in its current state is not a 1.x construct, it has
been redesigned several times and works afaik absolutely perfect. It
is used in production environments without any problems.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org