Curious if any other practitioners are running into issues with Oracle 12.2 and it's use of editionable views?
Currently running Appian 23.3, we are upgrading a business Oracle database we connect to from version 12.1.3 to 12.2.
With this version of Oracle, the best practice is promoted no longer reference base tables. Instead, editionable views are automatically created to utilize and this is what is mandated by our Oracle teams, via a synonym pointing to the editionable view on the table.
Appian (at least in my current version 23.3), does not seem to support the use of synonyms in this new fashion, as in the past we have always used synonyms within Oracle to satisfy data store validation and operation, for objects residing in different schemas, etc.
With Oracle 12.2, these editionable views are created automatically from the first 29 characters of a table name such as below:
Table: ORACLE_TABLE_NAMEView: ORACLE_TABLE_NAME#
This practice forces changes to the original synonym named "ORACLE_TABLE_NAME". While the synonym NAME remains the same, the "TABLE_NAME" property of the synonym changes from the same-named "ORACLE_TABLE_NAME", to "ORACLE_TABLE_NAME#" (now with a pound sign), and this FAILS data store validation in Appian.
We are then required to update @Table annotations as below, which creates a new version of the CDT and the associated production maintenance/support for running instances, etc, at launch time.
As we cannot follow Oracle best practice of accessing the table via the synonym at this time (as the synonym is the only object located in an 'acceptable' schema to access), we are forced to change to utilizing the editionable view directly which resides in the base schema, semi-violating Oracle best practices:
@Table(name="ORACLE_TABLE_NAME#" schema="SCHEMA")
I'll open a ticket as well, but wanted to start this thread for other thoughts on the topic and to note our current workaround.
Discussion posts and replies are publicly visible