Bug 116119

Summary: beforeSave method in ContentItem is not reliably setting content type association
Product: [Retired] Red Hat Enterprise CMS Reporter: Daniel Berrangé <berrange>
Component: domainAssignee: ccm-bugs-list
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: medium Docs Contact:
Priority: medium    
Version: nightly   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-17 22:39:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 113496, 116003, 116117, 116120    

Description Daniel Berrangé 2004-02-18 13:28:19 UTC 
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.
Comment 1 Daniel Berrangé 2004-02-18 17:08:33 UTC 
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....
Comment 2 Daniel Berrangé 2004-02-19 14:29:25 UTC 
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.