[C2] esql - ordbms support

[Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>]

Berin,

I'm currently considering ORDBMS support in esql, well, actually, I
do have a version here that does it for C2. Anyway, I'd like to share
some thoughts on it.

The simplest ORDBMS support would be to allow the user to get an
object from the query and to leave it to her/him how to deal with it.

In addition one could extend get-columns to extract advanced datatypes
as well. Over here on Informix IUS 9.21 these are mostly of
java.sql.Types.STRUCT for row types and java.sql.Types.OTHER for
everything else like sets, lists, bags. One way to determine the
correct type would be to try to cast the object to an appropriate
interface, say java.util.Set. 

How should the structure of an attribute be represented? Nesting alone
wouldn't do since it wouldn't be possible to distinguish sets from
structs. So we should introduce something like "sql-list", "sql-row",
"sql-set", plus some "sql-item" elements to capture e.g. the list
members. So far I didn't find a way e.g. to name the components of a
struct. 

Would it make sense to provide specialized "get-" methods for complex
data types like "get-set"? (I don't think so.)

Another issue arises: encoding. "First class" attributes can be read
through getBytes() and converted afterwards. But nested attributes
only offer a toString() method, right? Would it be right to disable
the encoding parameter on nested attributes?

Another feature could be, to manipulate the type mapping table for a
jdbc connection and allow to map advanced or user defined types to
map to a user provided java class. Jdbc drivers sometimes come with a
utility to create such a class from a db schema.

Other features I'd like to see in esql (and have a working copy
already ;-)

Supplying column names / numbers from a XSP variable (esql differs
from other taglibs in that it doesn't use the 
"<esql:param name="column">1</esql:param>" notation, instead it uses
"<esql:column></esql:column>". I would like to change that.)

Offer some direct paths to the esql code, like "get-metadata",
"get-column-type", "get-object", or even "get-resultset"

Make "get-xml" more powerful so that the db needs only to store
fragments of an xml document. Currently, only a root element without
any attributes is allowed here. Thus it is not possible e.g. to
specify a namespace for the fragment. (not done yet)

BTW since it is possible to include other logicsheets, would it be
wise to put all utility tags (copy-all, get-nested-content,
get-parameter and the like) to a common logicsheet so that they could
easily be used by new logicsheets?

TIA for comments.

	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