Return-Path: <atagunov@nnt.ru>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 53817 invoked from network); 11 Jan 2001 21:57:49 -0000
Received: from mail.ursus.ru (HELO ursus.ru) (195.96.66.197)
  by h31.sny.collab.net with SMTP; 11 Jan 2001 21:57:49 -0000
Received: from [195.96.66.194] (HELO anthony) by ursus.ru (Stalker SMTP Server
 1.7) with SMTP id S.0000198873 for <cocoon-dev@xml.apache.org>;
 Fri, 12 Jan 2001 00:56:41 +0400
From: "Tagunov Anthony" <atagunov@nnt.ru>
To: "cocoon-dev@xml.apache.org" <cocoon-dev@xml.apache.org>
Date: Fri, 12 Jan 2001 00:59:50 +0300
Reply-To: "Tagunov Anthony" <atagunov@nnt.ru>
Priority: Normal
X-Mailer: PMMail 2000 Professional (2.10.2010) For Windows NT (4.0.1381;6)
In-Reply-To: <Pine.LNX.4.30.0101102144470.458-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
Subject: Re: Cocoon 1.8.1 (was: Re: generate <esql:excute-query> dynamically
 ?)
Message-Id: <S.0000198873@ursus.ru>
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

On Wed, 10 Jan 2001 21:48:28 -0500 (EST), Donald Ball wrote:

>On Thu, 11 Jan 2001, Robin Green wrote:
>
>> The other minor thing is (don't flame me, Donald, you were the one who
>> wanted to finalize the esql namespace), I think the encoding support in esql
>> should use elements instead of attributes so that we can use
>> get-nested-whatsits. But it's late.
>
>not to late imho. i didn't do the encoding stuff, it's not even mentioned
>in the schema. i'm more than willing to change it in favor of a better
>scheme. if anyone objects, i'm willing to be overruled, but otherwise i
>say we change it.
>
>- donald
>

Guys! May I come up with some more propositions?

Well, (in the order of importance)

1) as long as we have <esql:get-string column=".." encoding="windows-1251"/>, it would be hingly reasonable
(and highly usefull!) to have  <esql:parameter encoding="windows-1251"/>. I've tested it myself (there's my
patch somewhere there in the mailist that does it via setBytes()) and it works!

2) (semantics, not schema) is it reasonable not to have <esql:results> when <esql:no-results> is instantiated?
e.g. is it reasonable to have <esql:results> and <esql:no-results> be mutually exclusive? (this would simplify xslt processing
of the result)

3) guys! do you really think that having a way to catch exception somewhere around
=============
      }
      <xsl:apply-templates/>
    } finally {         /*line 278, v1.41 */
      try {
        if(!_esql_connection.connection.getAutoCommit()) {
=============
is a bad idea? What I'm speaking about is having some 
=============
 <esql:connection>
     <esql:error-results>
            <error>Can't connect to database: <esql:get-message/></error>
     </esql:error-results>
   ..
=============
at <esql:connection> level? 

Of cource, I could catch this in /*<xsp:logic>try{}cathc</xsp:logic>*/ 
but would not this make the error-handling more straightforward?

4) we're running an unreliable database and are quite limited on the licenses. 
And caching quite suits our needs.
So we have reasons to open and close jdbc connections every time the
xsp is executed.
Is it possible to 
have some tag like <esql:pool> (<esql:nopool>?) that would have the following result:
it would accept the same values as <esql:pool> but would extract
dburl user and pass from where they are stored and open connection?
So we wouldn't have to give dburl, user and pass everywhere, just the "name" of
database configuration but still we would have NO connection pooling?

Best Regards, 
Tagunov Anthony