Ever thought about what happens when you insert a row into a join view? And what happens when you delete a row from a join view? Thus, to be modifiable, a join view must also preserve a key from at least one of its tables.
A key-preserved table is the most important requirement for a join view to be modifiable.
CREATE FORCE VIEW my_dataview ( key1, key2, column_from_table1, column_from_table2 ) AS SELECT t1.key1, t1.key2, t1.column_from_table1, t2.column_from_table2 FROM table1 t1 LEFT OUTER JOIN table2 t2 on t1.key1 = t2.key1 and t1.key2 = t2.key2; Unfortunately that didn't work.
But it’s still quite common for development work to take place in an environment that is a little lax about this rule, with developers connecting as the data owner to write code.
This could leave you with code that seemed to work in the development environment but suddenly needs a change which grants excess privileges to the end-user before it runs in the production environment.
But even adding in the separate columns to the view did not change anything, except replicating data unnecessarily.
I know it is possible to update a view using an INSTEAD OF trigger, but I would prefer to keep this as clean I can -- that seems more like a hack than a solution anyways.