That's a new feature in 12c. That's how identity columns work in Oracle. You can add an identity column using SQL Developer. I think they're just trying to make it easier to create the equivalent of an 'Autonumber column' as in the other Database product you mention....
Although I feel the trigger is unnecessary IO (on our system) so I don't advocate using it, I'd rather insert into a table using sequence.nextval.
Hi Vic, thanks for your reply.
I know this is a new feature in 12c. What i find strange is the creation of the trigger, that bring the identity management to the same level of the previous version (11g and before): sequence + trigger.
If I create a table with an identity column, the default value of this column is something like ""MY_OWNER"."ISEQ$$_115319".nextval" with the ISEQ$$_115319 sequence created and managed by default.
But there is NO trigger associated to the table.
That's why I don't understand the reason why the Migration process in SQL Developer create a trigger associated to the table THOUGH I check the Identity option in Oracle 12c.
This is an expected behavior if i had no checked the "Identity columns" option.
I think we need a 12 jdbc driver to activate the 12c db features, what version of sqldev are you using in your migration project?
I'm using sqldeveloper 4.0.3.
How can i know if we have 12 jdbc driver? And, eventually, how can i handle to get them?
I don't think it's a matter of driver. It's the database engine's task to allow for this new feature. Identity column is, from the SQL Developer's perspective, an extension to the create table's (and similar) column definition clause.
The table definition as provided in your initial comment seems correct. The trigger generated is an after insert trigger. It does not generate the ID value. Generation is left to the 12c new feature. So the short answer is 12c identity generation is utilized in the migration task.
That after insert trigger just saves the ID value generated to the utils.identity_value variable. I don't know what the utils package stands for in the migration task, but the whole solution seems for me as if it was something like a returning into clause in the insert statement. If you don't need, you can delete that trigger. It should not break ID-generation, but it might break some other code in the master.sql.