Dear Tom,
I have a question related to Oracle EBR.
We are using Oracle 19C (Enterprise Edition) & now moving to be EBR compliant.
Currently we do have DML triggers defined on tables.
These table have foreign key constraints defined with cascade on delete option.
For instance, ORDER_LINE_TABLE has a foreign key referring to ORDER_TABLE with cascade when delete (deleting a record in ORDER_TABLE).
As per the Oracle guidelines, the recommended approach for creating triggers in general seems to be define them on editioning views (EVs), instead on real tables, for many good reasons.
But in this case, it is not possible to create the triggers on EVs due to cascade operation initiated by FK constraint is performed at real table level, thus not visible to triggers on the EV.
This limitation has been mentioned by Oren Nakdimon in below document:
https://db-oriented.com/2025/01/08/ebr-part-13-the-trouble-with-foreign-keys-with-on-delete-clause-and-related-triggers/ As a workaround for this, we have been testing on defining the DML triggers on the real tables, in this like scenarios. But we see some challenges when they are present especially while using Cross Edition (XE) Triggers during upgrades. Since XE triggers are operating on real table level, DML triggers would see those DML operations happening on real tables, hence, it is hard for us to have an isolation in upgrade period.
Even the above document says, I doubt it is a rare combination of having FKs with cascade & having DML triggers.
Do you have a better approach to define DML trigger in such scenarios, instead of the approach I mentioned above?
Thank you & Kind Regards,
Navinth
Unfortunately, to quote the video below: "There some awkwardnesses involved when it comes to EBR" :-)
https://youtu.be/4KI2uRAEh3A?list=PL22OaGrT53hVXrAYvG2CYnZ0eKvDxIcg8&t=1259 In my (limited) experience of real world customers using EBR, my observation has been that "on delete cascade" was removed in favour of doing it via code (I was fortunate enough to have customers that were using a strict PLSQL API to their tables, so this was not particularly difficult to implement).
I agree that its an unfortunate restriction, but as per the video above, it falls into the "readying the application for EBR" phase.
(I know that's probably not the answer you were after).