Re: [Connotea-code-devel] more on DBIx::Class::CDBICompat

[Kieren D. <ki...@di...>]

On 14 Aug 2007, at 02:18, Martin Flack wrote:

> Kieren Diment wrote:
>> so this is an example of a problematic line:
>> my $time = $Bibliotech::Apache::QUICK{DB} ||   
>> $Bibliotech::Apache::MEMCACHE->get('DB');
>
> We fetch the latest database update time from the memcache (to  
> calculate last_updated times) and we memoize it so that we don't  
> keep asking memcache over and over in the same request.
>
> This is in service of being able to do proper 304 HTTP status  
> codes; we try not to hit the database if we know that the database  
> has not even been changed since the time the user reports they last  
> saw the page they are now requesting again. The various components  
> report a last_updated time and for the data-driven components its  
> usually just this DB time.
>
> This is by definition controller and model interacting.
>
> Do you know how this generally would be accomplished in Catalyst?


OK.  Throught the catalyst request cycle, you get access to a  
persistent $c object.  $c contains  things like $c->request and $c- 
 >response, $c->user (provided by the auth plugins) $c->action and so  
on.  In general the $c object is available in everything that does  
"use base 'Catalyst::Controller'" and use "base 'Catalyst::View'".   
Models are slightly different and by default you don't get $c -  
they're just a package automatically picked up by  
Module:::Pluggable::Object when the app runs initially.  However if  
your model supports the ACCEPT_CONTEXT method (documented in  
Catalyst::Manual::Intro) then you do get access to $c in your model.

HOWEVER ... it is generally considered good practice to have your  
Catalyst::Model a thin wrapper around a model that will work  
standalone.  This means for example that you can use your model  
standalone with a shell script for example.  In the case of Connotea  
this is probably not nescessary, but this thin wrapper around a fat  
model approach is still well worthwhile because it will make the code  
much more modular.  Bibliotech does pretty heavy lifting in the  
database department, and a standalone database only model would make  
better abstraction, and greatly reduce cognitive overhead for your  
developers.

Having said this I had a look at the docs for DBIx::Class::Cursor and  
DBIx::Class::Cursor::Cached and it looks very much to me like you are  
getting transparrent caching in the deal and wouldn't need  
ACCEPT_CONTEXT or equivalent.  The next bit is crucial:  your caching  
stuff has no test coverage.  moving to CDBICompat, and the  
cursor::cached engine buys you all thier test coverage for free, with  
better separation and better debugging tools.  I'd do this myself,  
but it's not my code, so I'd rather that someone who was familliar  
with it did the reverse plumbing.  Once that's done I'm likely to get  
around to doing a demo refactor of one of the methods to DBIC.

Oh.  I made a #connotea channel on irc.perl.org - although our  
timezones are off, I'm just going to idle there until someone else  
turns up :-)