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 :-)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Connotea-code-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/connotea-code-devel
