Re: draft final version of the esql namespace

[Nicola Ken Barozzi <ni...@supereva.it>]

From: "Donald Ball" <ba...@webslingerZ.com>

> after much discussion and cogitation, i submit the following pseudoschema
> as the proposed final skeleton of the esql namespace:
>
> <esql:connection>
>  <esql:driver>org.postgresql.Driver</esql:driver>
>  <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
>  <esql:username>test</esql:username>
>  <esql:password>test</esql:password>
>  <esql:execute-query>
>   <esql:query>select id,name from department_table</esql:query>
>   <esql:results>
>    <header>header info</header>
>    <esql:row-results>
>     <id><esql:get-int column="id"/></id>
>     <name><esql:get-string column="name"/></name>
>    </esql:row-results>
>    <footer>footer info</footer>
>   </esql:results>
>   <esql:update-results>
>    there were <esql:get-updated-rows/> rows updated
>   </esql:update-results>
>   <esql:error-results>
>    the query failed for some reason: <esql:get-message/>
>   </esql:error-results>
>  </esql:execute-query>
> </esql:connection>
>
> conformant implementations shall work as follows:
>
> 1. connections are opened at the start connection element tag and closed
> at the end connection element tag.
>
> 2. multiple queries may be executed in the same connection
>
> 3. if a query returns a resultset, the children of the results element, if
> any, are instantiated and the children of the results element's
> row-results child are instantiated for each row in the resultset.
>
> 4. if a query returns a number of rows, the children of the update-results
> element are instantiated.
>
> 5. if a query results in a sql error and an error-results element exists,
> its children are instantiated and the processor will attempt to
> continue.
>
> 6. the execute-query and connection elements may appear underneath the
> results, row-results, update-results, or connection elements.
>
> comments and suggestions are welcome. if everything thinks this is okay,
> i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> etc.) begin writing a formal schema for this and bring the c1 and c2
> implementations into line with the specification.

I think it's really cool :-)
I thought that maybe different "taglibs" per SQL command could have
been better, but the SQL is a string you cannot control, and people
might end putting INSERT in a SELECT execution tag! :-P
Well, this is also elegant I think.
The tags are in this order:

1-definitions
2-input (query)
3-output(results)
4-info on execution
5-errors

and output has:
3-1-output-begin
3-2-3x-output-cycle(with nestings)
3-3-output-end

I like it! :-)
IMHO it is important that all tags are to be "active" and usable with
every SQL command; the reasons are above.

Good! :-)

nicola_ken

Re: draft final version of the esql namespace

[Donald Ball <ba...@webslingerZ.com>]

On Tue, 7 Nov 2000, Nicola Ken Barozzi wrote:

> I thought that maybe different "taglibs" per SQL command could have
> been better, but the SQL is a string you cannot control, and people
> might end putting INSERT in a SELECT execution tag! :-P

i think you've got a good argument there, it's just not in line with what
i needed. i think you could write such a logicsheet as a wrapper around
the esql logicsheet if you wanted to, tho.

- donald

Re: draft final version of the esql namespace

[Donald Ball <ba...@webslingerZ.com>]

On Tue, 7 Nov 2000, Nicola Ken Barozzi wrote:

> I thought that maybe different "taglibs" per SQL command could have
> been better, but the SQL is a string you cannot control, and people
> might end putting INSERT in a SELECT execution tag! :-P

i think you've got a good argument there, it's just not in line with what
i needed. i think you could write such a logicsheet as a wrapper around
the esql logicsheet if you wanted to, tho.

- donald