cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Cocoon database access strategy
Date Mon, 02 Jul 2007 08:25:35 GMT
Hello Andrew,

I am not sure, but I really do not understand your email? You are talking about caching the
prepared statement, but I do not get what you try to achieve with it...?

The sql transformer will never cache, because it does not implement CacheableProcessingComponent.
IMO, there is only one single way to cache the sql transformer properly but you would have
to add your own cache impl (if anybody interested I could explain, otherwiser i do not bother,
but it is a combination of the cached: protocol wrapper with a asynchronous get in which the
result of the sql statement would be crc32 compared with the previous one: if different, the
cachedentry should be kicked out, if not, keep the old one). This way, you really do have
cached pipelines in cocoon with the sql transformer....only drawback is asynchronous get,
which means that if the result is depending on the sql statement (like first INSERT) then
it is not possible (never imo)

Ard

> 
> 
> Bloody hotmail appears to have stripped out all my sql & xsl 
> namespaced XML elements :-(
> Anyone know how to disable this in the new "improved" interface?
> 
> > From: ats37@hotmail.com
> > Date: Sun, 1 Jul 2007 02:35:03 +0100
> > 
> > > Date: Sun, 24 Jun 2007 11:14:38 +0200
> > > From: tobia.conforto@linux.it
> > > 
> > > Rob Frohwein wrote:
> > > > - query1.xml    using SqlTransformer on table1
> > > > - cleansql.xsl  rename 
> > > > - process1.xsl  reorganize
> > > > - query2.xsl    query different table
> > > > - cleansql.xsl  rename 
> > > > - process2.xsl  reorganize
> > > > ...
> > > >
> > > > It works, but is this the "right" approach?
> > > 
> > ...
> > > 
> > > It works well, but it has some security and performance 
> problems (more
> > > on that in a minute) so I'd like to know if there's a 
> better approach.
> > > 
> > > One of the problems with the SQL Transformer, when used 
> with XSLT in
> > > this fashion, is that it lacks support for prepared statements and
> > > parameters.  Without parameters ( in XSP) you have the
> > > same security problems you would have in badly written PHP:
> > > 
> > > 	SELECT ...
> > > 	FROM ...
> > > 	WHERE name = ''
> > > 
> > > You did think of this problem, didn't you? :) I can post 
> my:addslashes()
> > > if you want.  In any case you will agree that composing 
> queries this way
> > > is... "antiquated" at best.
> > > 
> > > The compiled query cannot be cached (as a prepared 
> statement would),
> > > because it changes with every request, and I fear the SQL 
> Transformer
> > > doesn't even try to cache it.
> > 
> > What about
> > 
> 
> substitute brackets with less than & greater than symbols as 
> appropriate...
> 
> (sql:execute-query xmlns:sql="http://apache.org/cocoon/SQL/2.0")
> (sql:query) 
> SELECT ...
> FROM ...
> WHERE name = ?
> (/sql:query)
> (sql:in-parameter nr="1")
> (xsl:attribute name="value")(xsl:value-of 
> select="$whatever"/)(/xsl:attribute)
> (/sql:in-parameter)
> (/sql:execute-query)
> 
> > ?  The in-parameter may change, but the query itself 
> doesn't so the prepared statement ought to cache it.
> > 
> > Admittedly, as written above you've got to supply the 
> in-parameter value as a map:parameter to the XSL transformer 
> rather than the SQL transformer, since it's not valid XML to 
> put elements inside attributes (so 
> 
> (sql:in-parameter nr="1" value="(sql:substitute-value 
> name="whatever"/)"/)
> 
> >isn't valid).  To work around that, we customised the 
> transformer so that in-parameter can take either a constant 
> value (in the value attribute) or the name of a supplied 
> parmeter (in a new "param" attribute) which is substituted in 
> the same fashion as substitute-value.  That shortens it to
>  
> (sql:query) 
>  SELECT ...
>  FROM ...
>  WHERE name = ?
> (/sql:query)
> (sql:in-parameter nr="1" param="whatever"/)
>  
> 
> Andrew.
> 
> _________________________________________________________________
> 100’s of Music vouchers to be won with MSN Music
> https://www.musicmashup.co.uk/index.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message