Bug 116119 - beforeSave method in ContentItem is not reliably setting content type association
beforeSave method in ContentItem is not reliably setting content type associa...
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise CMS
Classification: Retired
Component: domain (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks: 113496 116003 116117 116120
  Show dependency treegraph
 
Reported: 2004-02-18 08:28 EST by Daniel Berrange
Modified: 2007-04-18 13:03 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-17 17:39:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2004-02-18 08:28:19 EST
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 Berrange 2004-02-18 12:08:33 EST
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 Berrange 2004-02-19 09:29:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.