问题描述
假设我们有以下表结构:
Let's say we have the following table structures:
documents docmentStatusHistory status
+---------+ +--------------------+ +----------+
| docId | | docStatusHistoryId | | statusId |
+---------+ +--------------------+ +----------+
| ... | | docId | | ... |
+---------+ | statusId | +----------+
| ... |
+--------------------+
可能很明显,但值得一提的是,文档的当前状态是最后输入的状态历史记录.
It may be obvious, but it's worth mentioning, that the current status of a document is the last Status History entered.
系统的性能缓慢但肯定会下降,我建议将上述结构更改为:
The system was slowly but surely degrading in performance and I suggested changing the above structure to:
documents docmentStatusHistory status
+--------------+ +--------------------+ +----------+
| docId | | docStatusHistoryId | | statusId |
+--------------+ +--------------------+ +----------+
| currStatusId | | docId | | ... |
| ... | | statusId | +----------+
+--------------+ | ... |
+--------------------+
这样我们就可以在应有的位置获得文档的当前状态.
This way we'd have the current status of a document right where it should be.
由于遗留应用程序的构建方式,我无法更改遗留应用程序的代码以更新文档表上的当前状态.
Because the way the legacy applications were built I could not change the code on legacy applications to update the current status on the document table.
在这种情况下,我不得不为我的规则打开一个例外,以不惜一切代价避免触发器,仅仅是因为我无法访问遗留应用程序代码.
In this case I had to open an exception to my rule to avoid triggers at all costs, simply because I don't have access to the legacy applications code.
我创建了一个触发器,每次将新状态添加到状态历史记录时,它都会更新文档的当前状态,它的作用就像一个魅力.
I created a trigger that updates the current status of a document every time a new status is added to the status history, and it works like a charm.
然而,在一个晦涩且很少使用的情况下,需要删除最后一个状态历史记录,而不是简单地添加一个新的.所以,我创建了以下触发器:
However, in an obscure and rarely used situation there is a need to DELETE the last status history, instead of simply adding a new one. So, I created the following trigger:
create or replace trigger trgD_History
after delete on documentStatusHistory
for each row
currentStatusId number;
begin
select statusId
into currentStatusId
from documentStatusHistory
where docStatusHistoryId = (select max(docStatusHistoryId)
from documentStatusHistory
where docId = :old.docId);
update documentos
set currStatusId = currentStatusId
where docId = :old.docId;
end;
这就是我遇到臭名昭著的错误 ORA-04091
的地方.
And thats where I got the infamous error ORA-04091
.
我明白为什么我收到此错误,即使我将触发器配置为 AFTER 触发器.
I understand WHY I'm getting this error, even though I configured the trigger as an AFTER trigger.
问题是我看不到解决此错误的方法.我在网上搜索了一段时间,目前没有找到任何有用的东西.
The thing is that I can't see a way around this error. I have searched the net for a while and couldn't find anything helpful so far.
及时,我们将使用 Oracle 9i.
In time, we're using Oracle 9i.
推荐答案
变异表错误的标准解决方法是创建
The standard workaround to a mutating table error is to create
- 一个包含一组密钥的包(即本例中的 docId).临时表也可以使用
- 初始化集合的 before 语句触发器
- 一个行级触发器,使用每个已更改的 docId 填充集合
- 一个 after 语句触发器,它遍历集合并执行实际的 UPDATE
有点像
CREATE OR REPLACE PACKAGE pkg_document_status
AS
TYPE typ_changed_docids IS TABLE OF documentos.docId%type;
changed_docids typ_changed_docids := new typ_changed_docids ();
<<other methods>>
END;
CREATE OR REPLACE TRIGGER trg_init_collection
BEFORE DELETE ON documentStatusHistory
BEGIN
pkg_document_status.changed_docids.delete();
END;
CREATE OR REPLACE TRIGGER trg_populate_collection
BEFORE DELETE ON documentStatusHistory
FOR EACH ROW
BEGIN
pkg_document_status.changed_docids.extend();
pkg_document_status.changed_docids( pkg_document_status.changed_docids.count() ) := :old.docId;
END;
CREATE OR REPLACE TRIGGER trg_use_collection
AFTER DELETE ON documentStatusHistory
BEGIN
FOR i IN 1 .. pkg_document_status.changed_docids.count()
LOOP
<<fix the current status for pkg_document_status.changed_docids(i) >>
END LOOP;
pkg_document_status.changed_docids.delete();
END;
这篇关于Oracle 删除触发器后...如何避免变异表 (ORA-04091)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!