So it looks like it'd create the column as an "INTEGER" again, so on the next attempt I'd be back where I started.
ALTER TABLE CAM.ADDRESSES DROP CONSTRAINT ADDRESSES_PK CASCADE ; DROP INDEX CAM.ADDRESSES_PK ; DROP TRIGGER CAM.ADDRESSES_ROW_ID_TRG ; ALTER TABLE CAM.ADDRESSES RENAME TO bcp_ADDRESSES ; CREATE TABLE CAM.ADDRESSES ( ROW_ID INTEGER NOT NULL , [...] ); INSERT INTO CAM.ADDRESSES (ROW_ID ,[...] ) SELECT ROW_ID , [...] FROM bcp_ADDRESSES ; CREATE UNIQUE INDEX CAM.ADDRESSES_PK ON CAM.ADDRESSES ( ROW_ID ASC ) [...] ; ALTER TABLE CAM.ADDRESSES ADD CONSTRAINT ADDRESSES_PK PRIMARY KEY ( ROW_ID ) USING INDEX CAM.ADDRESSES_PK ;
, which was annoying but I could just delete all of those lines. Now that it wants to recreate the table altogether, it's harder to work around. But maybe the table recreation is due to the index business, which it didn't bother me about before.)
alter column addresses modify (row_id integer)
Now that it wants to recreate the table altogetherStorage properties are tracked also in DM 184.108.40.2067 - change in data type can lead to "recreate table" sequence if you explicitly set it for that table in "Data type conversion" tab. Some changes in storage properties (there is a "Storage properties" tab you can check it)
About Integer data type - it won't report difference if logical type integer is mapped to Integer data type or to Number(38). We'll improve it to cover mapping to Number as well.I just did some experiments and learned something about Oracle today. If you create a column as type "INTEGER" and look at the table in SQL Developer (3.0.04)'s Schema Browser's "Columns" tab, it says that the column is of type "NUMBER(38,0)", but it isn't. The USER_TAB_COLUMNS view says that the DATA_PRECISION is null, not 38, with DATA_SCALE 0. That explains why the Modeler sees the model's "INTEGER" or "NUMBER(38)" is different from the database column's precision-less data type. If the database column is explicitly created as a "NUMBER(38,0)", and USER_TAB_COLUMNS.DATA_PRECISION is really 38, the Modeler reports that as type "NUMBER(38)", which is sees as the same as the model's "INTEGER". Very interesting.