You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Elias Karakoulakis <ek...@manolito.image.ece.ntua.gr> on 2002/03/31 19:58:55 UTC
ESQL retake
Hello all,
I attach a protomorph of what I think will be the notorious ESQL
logicsheet rewritten almost from scratch. I need your feedback on this,
since I think it will be difficult to reimplement it without your
opinions!
The main reason behind such a foolish attempt (*hehe, scorn me later*) is
the inherent complexity of a system that's built on patches and
suggestions for almost 3 years now (DB: flame me later :-). Take a look at
it, because I think it's worth to think of cleaning various other parts of
Cocoon later on...
take a look at readme.txt, it contains my notes on my vain efforts..:-P
Elias
Re: ESQL retake
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 31.Mar.2002 -- 08:58 PM, Elias Karakoulakis wrote:
> Hello all,
>
> I attach a protomorph of what I think will be the notorious ESQL
> logicsheet rewritten almost from scratch. I need your feedback on this,
> since I think it will be difficult to reimplement it without your
> opinions!
And I need your comments to understand your ZIP :-) i.e. what are
those files and why is there a .cocoon2 file?
[your readme]
> Ignition-sequence for my efforts: nested groups
> => -PITA- to debug/implement with the current logicsheet
I beg to differ.
> => no aggregates! what's the use in groups without aggregate functions ?!
I don't think it is a good idea to create your own SQL inside a
logicsheet. Grouping is fine as long as it's used to /remove/
/duplicate/ /values/ i.e. formatting -- everything else is no business
for the esql logicsheet.
e.g.
john doe | cs101 john doe | cs101
john doe | cs102 => | cs102
jane doe | cs101 jane doe | cs101
> so I took a "serialized" approach to the problem:
> 1) first, I write a properly defined Schema for ESQL.
Great! A schema definition would help a lot.
> 2) then, I map schema types to xsl templates.
A bit confusing at first...
> 3) finally, I try to define the needs of the helper class and move as much
> code away from the logicsheet as possible.
OK -- could you be a bit more specific on what you actually moved
(apart from the grouping stuff)? BTW your switch style for multiple
values reads terrible...
> My initial target is to make this implementation of ESQL 100% compatible
PLEASE use a different namespace and prefix! Whatever you do -- as
long as it is not a proven drop in replacement your approach needs to
live happily together with the original esql. It might require quite
some time to prove the compatibility.
> with the current logicsheet. However, I obsoleted the usage of
> <esql:get(datatype)/> tags because it's meaningless to map JDBC datatypes
> to a weakly-typed environment such as XML text nodes.
Yes and no. For print out you're right. For logic it's essential.
> Questions:
> 1) backward compatibility: how big an issue?
*BIG*, *VERY BIG*
> 2) multiple connections per logicsheet: would we be needing them?
We need everything we have.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ESQL retake
Posted by Tim Myers <ph...@stserv.hcf.jhu.edu>.
Hi Elias,
Instead of replying to your mail, i'll reply to your readme.
> the inherent complexity of a system that's built on patches and
> suggestions for almost 3 years now (DB: flame me later :-). Take a look at
That may be a good thing. We'll see.
=> no aggregates! what's the use in groups without aggregate functions ?!
i'm not sure this justifies a complete rewrite.
> 1)...
> 2) then, I map schema types to xsl templates.
of course. Nice schema, by the way.
>3) finally, I try to define the needs of the helper class and move as much
> code away from the logicsheet as possible.
These will hopefully fall into place for you.
> My initial target is to make this implementation of ESQL 100% compatible
> with the current logicsheet. However, I obsoleted the usage of
> <esql:get(datatype)/> tags because it's meaningless to map JDBC datatypes
> to a weakly-typed environment such as XML text nodes.
Questions:
1) backward compatibility: how big an issue?
If you use a different namespace, it can be none.
i.e:
esql="http://apache.org/cocoon/SQL/v3"
2) multiple connections per logicsheet: would we be needing them?
nested queries:
oh yes. OT: wanna see something cool? see attached: messageboard.xsp.
multiple connections:
why not? they are no harder than nested queries. See how they are done now.
I think it is beautiful.
Version history:
0.01: basic functionality, compiles and executes esql example page
cool.
what i want to know is,
is it going to fix your original problem?
I did some more thinking about it. What are you using as your odbc-jdbc bridge? I spent about a day trying to get esql to work in jdk 1.4 because it has a jdbc2 compliant bridge driver. For production work, i use mysql and the gpl'd mysql driver.
I couldn't figure out why it was acting like you were getting an exception, and
not printing the stack trace for you. There are a couple of cases where the
current esql logicsheet will swallow exceptions. One corner my grouping code
cuts is always doing a resultSet.getString and a string comparison no matter
what the column type really is. Some jdbc drivers might not take kindly to
that. I'm not sure.
will your code allow nested groups?
one of my considerations was arbitrary nesting.
Tim
Re: ESQL retake
Posted by Tim Myers <ph...@stserv.hcf.jhu.edu>.
Hi Elias
> The main reason behind such a foolish attempt (*hehe, scorn me later*) is
> the inherent complexity of a system that's built on patches and
If you're going to rewrite esql, why not refactor it a little harder?
break it into an esql logicsheet that just does enough to get you a resultset,
and one or several resultset logicsheets that let you do iteration over results
in various ways or that have no method for iteration at all. A resultset
logicsheet that just implements your get-column element, combined with the
nestible esql sheet that already exists would provide maximum flexibility for
writing logicsheets.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org