Bug 102884 - Folder.getItems() doesn't fetch type name property
Folder.getItems() doesn't fetch type name property
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Archit Shah
Jon Orris
:
Depends On:
Blocks: 100952
  Show dependency treegraph
 
Reported: 2003-08-22 06:20 EDT by Daniel Berrange
Modified: 2007-04-18 12:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-07 17:27:22 EDT
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 2003-08-22 06:20:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
The Folder.getItems() method returns a Folder.ItemCollection object. If you then
call 'getTypeLabel' on this, you get a persistence error:

com.arsdigita.persistence.PersistenceException:  (root cause:
com.redhat.persistence.NotFetchedException: cursor does not fetch path:
item.type.label)
        at
com.arsdigita.persistence.PersistenceException.newInstance(PersistenceException.java:137)
        at
com.arsdigita.persistence.PersistenceException.newInstance(PersistenceException.java:109)
        at com.arsdigita.persistence.DataQueryImpl.get(DataQueryImpl.java:374)
        at
com.arsdigita.persistence.DataQueryDecorator.get(DataQueryDecorator.java:67)
        at
com.arsdigita.persistence.DataQueryDataCollectionAdapter.get(DataQueryDataCollectionAdapter.java:136)
        at com.arsdigita.domain.DomainQuery.get(DomainQuery.java:678)
        at com.arsdigita.cms.Folder$ItemCollection.getTypeLabel(Folder.java:625)


I tried to alter the ItemCollection query by doing in the 'init' method of
Folder.ItemCollection


            query.addPath(ITEM + "." + TYPE_LABEL);

However, I then get

com.redhat.persistence.engine.rdbms.RDBMSEngine$2: ORA-00918: column ambiguously
defined

        at
com.redhat.persistence.engine.rdbms.RDBMSEngine.execute(RDBMSEngine.java(Compiled
Code))
        at
com.redhat.persistence.engine.rdbms.RDBMSEngine.execute(RDBMSEngine.java:379)
        at
com.redhat.persistence.engine.rdbms.RDBMSEngine.execute(RDBMSEngine.java:212)
        at
com.redhat.persistence.engine.rdbms.RDBMSEngine.execute(RDBMSEngine.java:203)
        at com.redhat.persistence.Cursor.execute(Cursor.java:110)
        at com.redhat.persistence.Cursor.next(Cursor.java:94)
        at com.arsdigita.persistence.DataQueryImpl.next(DataQueryImpl.java:441)
        at
com.arsdigita.persistence.DataQueryDecorator.next(DataQueryDecorator.java:75)
        at com.arsdigita.domain.DomainQuery.next(DomainQuery.java:94)
        at
com.arsdigita.cms.ui.ItemSearchFolderBrowser$FolderTableModel.nextRow(ItemSearchFolderBrowser.java:311)

Because the query it generates is ambiguous:

select version as c_1,
       item_id as c_2,
       default_domain_class as c_3,
       name as c_4,
       master_id as c_5,
       display_name as c_6,
       object_type as c_7,
       has_live_version as c_8,
       is_folder as c_9,
       item_type__ct.label as c_10,
       item__ci.type_id as c_11
from (
    select 
      a.object_type, a.display_name, a.default_domain_class,
      i.master_id, i.item_id, i.parent_id, i.version, i.name,
      case when exists (select 1
                        from cms_items
                        where master_id = i.item_id)
        then 1 else 0 end as has_live_version,
      case when 0 = nvl(f.folder_id, 0) then 0 else 1 end as is_folder
    from 
      cms_items i, 
      acs_objects a, 
      cms_folders f
    where 
      i.item_id = a.object_id
    and 
      i.item_id = f.folder_id(+)
    and 
      i.parent_id = '135'
    and
      i.version = 'draft'
    and (exists (select 1 from cms_folders f
                 where f.folder_id = i.item_id)
         or
         exists (select 1 from cms_bundles b
	         where b.bundle_id = i.item_id))) st_,
     cms_items item__ci,
     content_types item_type__ct
where item__ci.item_id(+) = item_id and item_type__ct.type_id(+) = item__ci.type_id
order by is_folder desc, item_id desc;


The Folder#getItems method used to be used by FolderBrowser, however, in Troika
this was changed to Folder#getPrimaryInstances. It is still used in
ItemSearchFolderBrowser which is where I'm seeing the problem.

There are three possible courses of action:

1. Fix the ItemsInFolder query in Folder-quieries.*.pdl to pull out the type label
2. Fix the addPath() method not to generate ambiguous SQL
3. Change ItemSearchFolderBrowswer to use Folder#getPrimaryInstances

In fact I think we need to do all three.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Run the following code:

  Folder.ItemCollection items = f.getItems()
  while (items.next()) {
     String label = items.getTypeLabel();
  }


Actual Results:  Persistence error

Expected Results:  No error.

Additional info:
Comment 1 Randy Graebner 2003-08-26 09:15:45 EDT
>Change ItemSearchFolderBrowswer to use Folder#getPrimaryInstances

I don't think that we should necessarily default to using the Primary Instance.
 For Carrefour, we have authors that speak 4 different languages so we need the
UI to be multi-lingual.  If we always show the French display name then it may
not make sense to the Italian author that is looking for the Italian item.  I
think that we should either stay with the bundle or use a language negotiation
tool similar to what Aram proposed to select out the correct language for the
given user.
Comment 2 Archit Shah 2003-08-29 13:32:51 EDT
The data queries are fixed on tip and 6.0 branch. In addition, the persistence
bug has been resolved on tip and I am waiting for some more testing before
pushing it to 6.0. However, this does not fully resolve the issue. getTypeLabel
now returns null because bundles don't have a content type. The fix is to set
the content type of the bundle to the that of its primary instance. That fix
requires an upgrade script. I believe that it is reasonable to push that into
the 6.0 branch as well.
Comment 3 Archit Shah 2003-09-03 18:29:03 EDT
bundles now have a content type on tip (35649) and branch (35651). 

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