有没有办法为Class::DBI提供缓存机制？

Question

我有一组继承自Class::DBI的相当复杂的ORM模块。由于数据很少更改，我正在考虑在此基础上使用缓存/记忆化层来加快速度。我找到了一个模块：Class::DBI::Cacheable，但在RT上没有评分或任何评论。如果有人使用过这个或任何其他Class::DBI缓存方案，我将不胜感激。

非常感谢。

Answer 1

我也有过很多次自己的ORM，我讨厌这么说！如果所有的获取都是通过一个api (或其子类)进行的，那么缓存/记忆化就非常简单。

对于任何基于唯一键的提取，您可以仅基于键的连接进行缓存。一种天真的方法可能是：

my %_cache;

sub get_object_from_db {
    my ($self, $table, %table_lookup_key) = @_;

    # concatenate a unique key for this object
    my $cache_key = join('|', map { "$_|$table_lookup_key{$_}" }
                       sort keys %table_lookup_key

    return $_cache{$cache_key}
        if exists $_cache{$cache_key};

    # otherwise get the object from the db and cache it in the hash
    # before returning
}

您可以使用CPAN上的Cache:：suite模块来实现缓存中的时间和内存限制，而不是使用散列。

如果您要缓存一段时间，您可能需要考虑一种使缓存中的对象过期的方法。例如，如果您的所有更新都通过ORM，那么您可以清除(或更新) update() ORM方法中的缓存项。

最后需要仔细考虑的一点是，每次返回的对象都是相同的，这是有影响的。例如，如果一段代码检索了一个对象并更新了一个值，但没有将该更改提交给数据库，则检索该对象的所有其他代码都将看到该更改。如果您正在将一系列操作串联在一起，这可能非常有用-它们都可以更新对象，然后您可以在结束时提交它-但这可能不是您想要的。我通常在对象刚从数据库中更新时设置一个标志，然后在setter方法中，如果对象更新了，就使该标志无效-这样，如果你真的想要一个新的对象，你总是可以检查那个标志。

Answer 2

在一些情况下，我们使用了自己的，但我们将其限制在分析表明我们需要提升的特殊情况下(例如大型连接)。由于我们的应用程序通常在DB访问之上使用自定义抽象层(类似于自行开发的ORM)，因此我们在那里实现了缓存。我们取得了令我们满意的好结果，而且不需要花费太多的努力。当然，由于我们没有使用CPAN ORM，所以对于使用CPAN缓存模块，我们也没有任何选择。

这是严格的逐个案例和选择加入。无论您最终是使用CPAN解决方案还是使用自己的解决方案，将其限制在分析指示您需要帮助的情况下可能是个好主意，并确保它是可选的，这样您的缓存就不会因为在您意想不到的时候处于活动状态而以微妙的方式破坏您的应用程序。

Answer 3

我以前在cache objects中用过memcached，但没有用过Class::DBI (ORM让我觉得很脏)。