Migration scripts for Manufacturing Light do not work correct with existing production records
Description
Environment
Activity
Carlos Ruiz April 15, 2015 at 11:09 PM
This is reported as a migration note to take into account for those migrating with old production:
http://wiki.idempiere.org/en/Migration_Notes#Production
The migration note points to this ticket
Carlos Ruiz October 28, 2014 at 8:23 PM
Bring additional comment from forums
https://groups.google.com/d/msg/idempiere-es/HTRYIZs-F4Y/YumW04WEYY4J
According to there is another line that must be modified in the script:
Line 207 must be:
ALTER TABLE M_ProductionLine ADD COLUMN M_Production_ID NUMERIC(10) NULL
;
Dirk Niemeyer November 28, 2012 at 7:58 PM
In script 862a_ManufacturingLight.sql there are 3 lines adding columns for mandatory data:
62 - ALTER TABLE M_Production ADD DocumentNo NVARCHAR2(30) NOT NULL
72 - ALTER TABLE M_Production ADD M_Product_ID NUMBER(10) NOT NULL
82 - ALTER TABLE M_Production ADD M_Product_ID NUMBER(10) NOT NULL
When there are existing records in the table these columns could not be filled with reasonable data because the concept behind the production records is diffenrent.
An approach was discussed in the weekly meeting (2012-11-28):
(14:23:14) a42niem: the best fix would be to empty m_production first and then apply migration
(14:26:12) CarlosRuiz: thinking if we better make those columns nullables - and enable the old production window in read-only mode for these records - and on the new window we can filter out the records with null product
(14:26:41) a42niem: yep, good idea
(14:27:31) a42niem: maybe we can use mandatory logic to make them mandatory in the new window
(14:27:54) CarlosRuiz: yes, overwrite mandatory
(14:29:25) a42niem: how to proceed? change the existing scripts? or "deprecate" them and create new ones?
(14:30:05) CarlosRuiz: interesting
(14:31:06) CarlosRuiz: I think we need both
(14:31:15) a42niem: hm, "bug fix" scripts to amend them won't work i guess, they come too late
(14:31:21) CarlosRuiz: change the existing scripts to drop the "NOT NULL" condition
(14:32:02) CarlosRuiz: hmmm - thinking
(14:33:40) CarlosRuiz: what if we write an additional script for people coming from 361 -> 862a_ManufacturingLight.sql.361
(14:34:36) CarlosRuiz: and we advice people to apply 862a_ManufacturingLight.sql if they have old production records and want to preserve that date
(14:34:38) CarlosRuiz: data
(14:35:34) CarlosRuiz: the only difference would be to change the NOT NULL by null on lines 72 and 81
(14:36:19) CarlosRuiz: or we can make an annotation on the migration script for people coming from 361
(14:38:10) Deepak: Annotation for executing failled script manually with suggested changes is good idea. We should consider ant script as it may try to run both script in case of keeping two version
(14:40:54) CarlosRuiz: and we create a wiki page for "Backward Compatibility Notes" and/or "Migrating from 361 Notes"
As reported in the forum (https://groups.google.com/forum/?hl=en&fromgroups#!topic/idempiere-es/HTRYIZs-F4Y and others) there are problems in applying the migration scripts or working with ML when there are entries already existing in the production tables.