At this moment 2Pack executes a commit statement on certain DDL statements, like CREATE TABLE.
This was developed that way because Oracle has an implicit COMMIT on DDL statements, and we wanted to make the behavior of 2Pack consistent between oracle and postgresql.
But postgresql doesn't have that restriction, so in principle a 2pack in postgresql can be rolled back even if it contains DDL statements (not in oracle).
Proposal here is to create a SysConfig key to drive if we want the actual behavior (2PACK_COMMIT_DDL) or exploit the full postgresql power on this.
Regards,
Carlos Ruiz
Environment
None
Activity
Show:
RedhuanO April 20, 2016 at 10:45 PM
Yes, that sounds right and more elegant. I better modernize to real iDempiere way. Gracias!
Carlos Ruiz April 20, 2016 at 9:22 PM
, you could try also to split the 2pack in two parts, one creating the tables, and the other inserting the initial data
Hi , the migration script for oracle is producing the error {{SQL> SQL> SQL> 2 ALTER TABLE AD_Package_Imp_Detail MODIFY Name VARCHAR2(2000) DEFAULT NULL * ERROR at line 1: ORA-01439: column to be modified must be empty to change datatype }} Please change the datatype to NVARCHAR2. Thanks. Regards, Dirk Niemeyer
Major
At this moment 2Pack executes a commit statement on certain DDL statements, like CREATE TABLE.
This was developed that way because Oracle has an implicit COMMIT on DDL statements, and we wanted to make the behavior of 2Pack consistent between oracle and postgresql.
But postgresql doesn't have that restriction, so in principle a 2pack in postgresql can be rolled back even if it contains DDL statements (not in oracle).
Proposal here is to create a SysConfig key to drive if we want the actual behavior (2PACK_COMMIT_DDL) or exploit the full postgresql power on this.
Regards,
Carlos Ruiz