RE: Cocoon database access strategy
Ard Schrijvers <a.schrijvers <at> hippo.nl>
2007-07-02 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 <at> hotmail.com
> > Date: Sun, 1 Jul 2007 02:35:03 +0100
> >
> > > Date: Sun, 24 Jun 2007 11:14:38 +0200
> > > From: tobia.conforto <at> 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 <at> cocoon.apache.org
> For additional commands, e-mail: users-help <at> cocoon.apache.org
>
>
RSS Feed