You really don't want this in DBIx::Class, you want fine grain control of when
to fetch from the database, etc. Anyone can build their layer on top of
DBIx::Class to implement caching.
Using something like memcached would save you some database hits, you can
either set the values to expire at a specified time / number of seconds, or you
can set/delete keys as part of the procedures at insert/update/delete on the
database.
If you you Postgresql, you can actually take advantage of PgPool, which will
give you the option to enable a caching layer…
Francisco
On Jan 11, 2013, at 4:01 AM, Alexander Hartmaier
<alexander.hartma...@t-systems.at> wrote:
> On 2013-01-10 16:15, Jesse Sheidlower wrote:
>> In one of my apps, I have a number of tables that contain values that
>> change very rarely. Think of something like a "category" table in an
>> e-commerce app--they're mostly static, but every now and then you need
>> to change or add or delete a category. These occasional changes do,
>> however, need to be made by a (privileged) user, rather than a
>> developer, so I can't just put them in the config file and edit this and
>> restart the app when necessary. Since I don't know when they might
>> change, I don't know how I could cache them, because when a change is
>> made it needs to take effect immediately.
>>
>> These tables are used on almost every request. The result is that most
>> of my controllers end up looking something like this, or having
>> something like this at the end of them:
>>
>> sub add : Local {
>> my ( $self, $c ) = @_;
>>
>> $c->stash->{title} = 'Add a new lemma';
>>
>> $c->stash->{batches} = $c->model('WordsDB::Batch')->search();
>> $c->stash->{statuses} = $c->model('WordsDB::Status')->search();
>> $c->stash->{regions} = $c->model('WordsDB::Region')->search();
>> $c->stash->{subjects} = $c->model('WordsDB::Subject')->search();
>>
>> $c->stash->{template} = 'add.tt';
>> }
>>
>> This means that almost every page generation hits the database a whole bunch
>> of
>> unnecessary times, and that all of my controllers are cluttered.
>>
>> This must be a fairly common problem. What's the best way to deal with
>> it--both the desire to persist what is mostly static data, and to keep
>> my controllers clean?
>>
>> Thanks.
>>
>> Jesse Sheidlower
>>
>> _______________________________________________
>> List: Catalyst@lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
> I'd LOVE to see that functionality in DBIx::Class::Schema so prefetches
> use the cached values to populate the related data instead of hitting
> the database.
>
> --
> Best regards, Alexander Hartmaier
>
>
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
> Handelsgericht Wien, FN 79340b
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> Notice: This e-mail contains information that is confidential and may be
> privileged.
> If you are not the intended recipient, please notify the sender and then
> delete this e-mail immediately.
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>
> _______________________________________________
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
Francisco Obispo
Director of Applications and Services - ISC
email: fobi...@isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
