【问题标题】:How do I create rows without refetching related objects?如何在不重新获取相关对象的情况下创建行?
【发布时间】:2017-02-08 01:31:43
【问题描述】:

我有this guy的相反问题。

我有一个曾经经常使用这种模式的应用程序:

$rs->create({ foo => 'bar',
              status => { label => 'Active' } });

在幕后 DBIC 将执行SELECT 以查明是否需要创建相应的状态对象,或者是否存在带有“活动”标签的状态对象。如果它确实存在,它的 ID 将用作我正在创建的对象中 FK 的值。

问题是,状态表几乎永远不会改变,而且状态也不多,所以 99.99% 的时间基本上是对数据库的浪费查询。我们曾考虑使用 ENUM,但对于应用程序来说还处于早期阶段,所以我们肯定会在最初的几周内弹出一些新的状态。与ALTER TABLE status CHANGE label label ENUM(...) 相比,插入在 *** 中的痛苦更少。此外,将它们放在一个表格中意味着我们可以轻松列出可能的值,以便 UI 构建下拉列表。

所以现在我们有一堆get_THING_id 函数,它们接受THING 标签并返回一个ID。 get_THING_id 函数是 memoized,我们这样做:

$rs->create({ foo => 'bar',
              status_id => get_status_id('Active') });

感觉不是很 DBIC-y,而且不得不到处导入它们很尴尬。

我们应该硬着头皮只使用 ENUM 吗?人们为这种小桌子做了什么?

【问题讨论】:

  • 是否可以使用第一个代码块中的语法将 Result 对象作为status 传递?
  • @simbabque 我没有,所以这意味着要保留一张像"Active" => $active_status 这样的地图,这基本上又是一种记忆。

标签: perl dbix-class


【解决方案1】:

我们的 DBIC 模式中有一个 ::Constants 类(包),它包含所有这些静态事物的常量。 如果此类表的内容发生更改,通常需要调整架构甚至应用程序逻辑,因此添加/更改常量不是问题。

【讨论】:

  • 所以您根本不会使用单独的status 表,而只是使用常量?我可以看到优势,但这是否意味着您的字段没有 FK 约束,因此您可以在其中放置随机值?
  • 我们确实有该表来使用约束来强制执行有效值。
猜你喜欢
  • 2012-04-14
  • 2014-06-09
  • 1970-01-01
  • 1970-01-01
  • 2016-03-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多