cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: sql tag-library
Date Wed, 10 May 2000 12:50:06 GMT
Brian P Millett wrote:
> 
> Donald Ball wrote:
> 
> > On Tue, 9 May 2000, Stefano Mazzocchi wrote:
> >
> > > While I like XInclude/XPath/XPointer/XLink capabilities very much, I'm
> > > still not confident about those who get scared about it. And I know many
> > > of them (all apache people that are not subscribed to this list).
> > >
> > > The XML world is a colorful one, but palettes are shifted.
> > >
> > > In the back on my mind, though, I feel dangers in the XPointer design
> > > patterns. I don't know why... but I can't remove this feeling from my
> > > head... puzzling...
> >
> > Can you elaborate? Cumbersome, I might grant you, but dangerous?
> >
> > > > that would indicate to the taglib that the connection should be retrieved
> > > > from a pool if possible, and stored in a pool if it's not already there.
> > > > Note this addition is completely independent of the inclusion mechanism;
> > > > it would be entirely possible to pool connections that aren't included
> > > > from a central data source but are manually written in each of the various
> > > > query tags.
> > > >
> > > > Comments?
> > >
> > > I think query optimizations, persitency, reuse and pooling should be
> > > integreated into the taglib design.
> > >
> > > Brian's idea of a <pool> element is not bad, maybe we should elaborate
> > > more on that...
> >
> > True, now that I reflect more deeply, the pool element is necessary to
> > indicate to the pool manager what parameters it should use (how many
> > connections max, how long connections can be idle, etc.). I can't check in
> > Brian's patch as is though since it's strongly tied to turbine and I'd
> > rather like to offer the ability to plug in different pool managers as
> > none of them are perfect, in license or in features. Brian, can you
> > document your pool syntax for us so that we can flesh it out some?
> 
> Ok, bear with me.  This is probably the wrong explanation, but here goes.  This
> is what I currently have with all of the short comings that Donald mentioned.
> This syntax was driven because of the work we are doing for the Missouri
> Botanical Garden.
> 
> I will show the new afterwards.
> 
> This is the current way to define a connection in a pool.  As Donald stated, I
> used the connection pool from Turbine because it was under the Apache license and
> more robust than the DBConnectionManager.
> 
> <sql:define> the tag to start the connection definition that is then stored in
> the pool.  It is referenced (Checked out/Checked in) with the "name".  We found
> that this was necessary to have different connections to the same database.  We
> found that we didn't have the granularity to control the attributes of the
> connection if we only used the jdbc/url/userid/passwd tupel.
> 
> We create a connection with certain default attributes that affect the way data
> is handled.  For example, row-element, doc-element, id-attribute are used by our
> xsl to display data differently depending on the views of data being worked on at
> the time.  We also need to have several connection open to different databases.
> Currently that is Informix, Oracle and soon we need to add Sybase.
> 
>  <sql:define name="tropicos">
>    <sql:driver>com.informix.jdbc.IfxDriver</sql:driver>
> 
> <sql:dburl>jdbc:informix-sqli://vitis:1526/ids_tropicos:informixserver=cbi_dbresearch</sql:dburl>
> 
>    <sql:username>XXXXXX</sql:username>
>    <sql:password>YYYYYY</sql:password>
>    <sql:skip-rows>0</sql:skip-rows>
>    <sql:count-attribute></sql:count-attribute>
>    <sql:max-rows>50</sql:max-rows>
>    <sql:tag-case>preserve</sql:tag-case>
>    <sql:doc-element>ROWSET</sql:doc-element>
>    <sql:row-element>ROW</sql:row-element>
>    <sql:null-indicator>omit</sql:null-indicator>
>    <sql:id-attribute>ID</sql:id-attribute>
>  </sql:define>
> 
> Ok, you get the picture.  We then used the <sql:execute-query> from the SQLTag
> library, but added the use-connection attribute to indicate which connection  we
> need.  For example:
> 
>     <sql:execute-query use-connection="helpdesk">
>       <sql:query>
> SELECT last_name, first_name, initials
> FROM EMPLOYEE
>       </sql:query>
>     </sql:execute-query>
> 
> Would
> 
> Then we also needed to override the default attributes of the connection, but did
> not want to globally change the attributes:
> 
>     <sql:execute-query use-connection="tropicos">
>       <sql:skip-rows><xsp:expr>counter</xsp:expr></sql:skip-rows>
>       <sql:count-attribute>fred</sql:count-attribute>
>       <sql:max-rows>10</sql:max-rows>
>       <sql:query>
> SELECT   family_id,family_name
> FROM     families
>       </sql:query>
>     </sql:execute-query>
> 
>     <sql:execute-query use-connection="helpdesk">
>       <sql:query>
> SELECT *
> FROM EMPLOYEE
> WHERE last_name = <request:get-parameter name="lastName"/>
>       </sql:query>
>     </sql:execute-query>
> 
> Ok, that is the way we are doing it now.  Here is the syntax of what I see to be
> the improvements.  These are driven because we MUST have a pool.  We are creating
> "VIEWS" that need to persist.
> 
> This is how I am thinking of the connection pool (which is much like Ricardo's)
> 
>  <pool:define name="tropicos">
>    <pool:driver>com.informix.jdbc.IfxDriver</pool:driver>
> 
> <pool:dburl>jdbc:informix-sqli://vitis:1526/ids_tropicos:informixserver=cbi_dbresearch</pool:dburl>
> 
>    <pool:username>XXXXXX</pool:username>
>    <pool:password>YYYYYY</pool:password>
> </pool:define>
> 
> This would create a new connection named "tropicos" and add it to the pool that
> is defined in the cocoon.properties (pool =
> org.apache.cocoon.processor.xsp.library.sql.util.db.pool.DBBroker)
> 
> Then the sql:execute would be as:
> 
>  <sql:execute-query>
>    <sql:use-connection><pool:get-connection name="tropicos"/><sql:use-connection>
> 
>    <sql:skip-rows>0</sql:skip-rows>
>    <sql:max-rows>50</sql:max-rows>
>    <sql:tag-case>preserve</sql:tag-case>
>    <sql:count-attribute>count</sql:count-attribute>
>    <sql:doc-element>ROWSET</sql:doc-element>
>    <sql:row-element>ROW</sql:row-element>
>    <sql:null-indicator>omit</sql:null-indicator>
>    <sql:id-attribute>ID</sql:id-attribute>
>    <sql:query>SELECT * FROM CUSTOMER;</sql:query>
>  </sql:execute-query>
> 
> Or if a pool was not used, the standard way would be used.
> 
> I'll be the first to mention that I need to read up on the various X<whatever>
> proposed standards.  The Xinclude seems good, however I do not understand it all
> yet, and I too have a feeling that "too many notes" apply.  More than anything,
> that just means that I need to do more homework.

Wow,

seems you did your homework pretty well to me, Brian :)

I like the inclusion of a pool and even more the use of Turbine code.

Now, the question: how do we make this work in standard Cocoon?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message