Bug 102884
| Summary: | Folder.getItems() doesn't fetch type name property | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Daniel Berrangé <berrange> |
| Component: | other | Assignee: | Archit Shah <archit.shah> |
| 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: | 2003-10-07 21:27:22 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: | 100952 | ||
>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.
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. bundles now have a content type on tip (35649) and branch (35651). |
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: