Description of problem: There still seems to be circumstances under which the beforeSave() method of ContentItem does not set the content type association. This is being exposed by the APLAWS bulk importer. Out of about 3000 items imported, approximately 1/2 of the top level items have a null type_id in cms_items. I'm trying to narrow it down to provide a reproducable test Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Run APLAWS bulk import 2. select count(*) from cms_items i where i.item_id in (select p.item_id from cms_pages p) where type_id is null 3. Actual results: Count is 1500 Expected results: Count is zero. Additional info: Test cases to follow.
At least part of the problem is as follows: The following code deals with the content type association: * Most content types have code in their no-arg initializer that does try { final ContentType type = ContentType.findByAssociatedObjectType (getSpecificObjectType()); setContentType(type); } catch (DataObjectNotFoundException donfe) {} * There is similar code in the beforeSave() method of ContentItem which runs when 'isNew()' is true. * When creating a ContentBundle, in its constructor there is code: setContentType(primary.getContentType()); The problems are: 1. We don't neccessraily create new items using the no-arg constructor, so the code in speciifc content types doesn't neccessarily ever run. 2. The ContnetBundle may (will) be created before its primary instance has ever been saved, so the beforeSave code in ContentItem willnot have been run either. Both of these problems combine to mean that nearly all imported content bundles have a null type_id. The solution to this is as follows: * Set the content type association in the 'initialize' method of ContentItem instead of beforeSave. This is possible because the only piece of data required to set content type is the 'objectType' property which will already have been setup by ACSObject#initialize. * Add an Assert to the beforeSave method of ContentBundle to ensure that if there is any ever change to this code we'll catch the fact that the bundle is missing its type_id association the momennt it is created, rather than when random bits of UI / publishing code break some time later. I still believe there is a bug somewhere related to firing of beforeSave events, because there are a number of items in the DB which don't even have type_id set for the instance itself. I am yet to reliably reproduce this particular problem though....
Fix for ensuring content bundle's type gets set is in p4 40561. This also includes a bunch of assertion to protect against this bug recurring in the future. Slightly disturbing is that I've still not been able to reliably reproduce the bug that causes the item's content type to not be set - although moving this code to the initialize() method instead of beforeSave() is quite likely good enough to fix it.