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 14:58:42 GMT
"Calendar generator DOM and for each working day element generate a <sql:query> to determine
whether appointment entries exist in a database for this day"....you lazy programmer!! :-)


What about implementing your own caldav implementation with cocoon generators and transformers,
add jms listeners, and use update events in combination with an eventcache to invalidate the
correct parts of the calendar frontend. Create caldav connectors to your application to combina
some calendars and import others....you really missed an opportunity here :-)   

Ofcourse, I am not serious: Cocoon is an enormeous toolbox, and there are like hundreds of
ways to achieve the same (though, I really think there are only a few proper ones)

Ard




The answet to that one is - it all depends.. on which Application Container, DBMS and JDBC
driver you are using.

It is good that you have discovered that you can do so much with the SQLTransformer. As you
know, I am very fond of using this component. I have no qualms about generating <sql:query>
elements based upon the shape of the XML DOM. As an example of how shameless I can be, I have
even been known to take the Calendar generator DOM and for each working day element generate
a <sql:query> to determine whether appointment entries exist in a database for this
day. The performance was fine and the solution very comprehensible and easy to extend. Of
course, the purist might cry foul but I see nothing fundamentally wrong with it. I recommend
this as a perfectly acceptable way of using the Cocoon pipeline as the Model which transforms
into the View as it's contents pass through it. The alternative of a stored procedure was
not available and, as you know, I am reluctant to incur the development and maintenance overhead
that some kind of Java object/relation model would require. 


On 02/07/07, Tobia <tobia.conforto@linux.it> wrote:
Andrew Stevens wrote:
> The problem I was replying to has to do with the caching of prepared
> statements within the database connection so that running the same
> statement with different parameters doesn't need the database server 
> to recompile the query each time.  That's what makes it "prepared"
> rather than just a Statement.

By the way, for the sake of completeness, who or what is responsible for
caching the statements?  The JDBC connector?  The database process? 

How does one check that it is actually caching anything, except by crude
benchmarking?


Tobia

---------------------------------------------------------------------
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