Bug 109397

Summary: ancestorsList in Category.getDefaultAncestors()
Product: [Retired] Red Hat Web Application Framework Reporter: Carsten Clasohm <clasohm>
Component: otherAssignee: ccm-bugs-list
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 6.0   
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: 2006-07-12 09:03:25 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: 108447    

Description Carsten Clasohm 2003-11-07 14:12:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Description of problem:
Category.getDefaultAncestors() should split the "ids" string by "/" to
generate the ancestorsList.

Coincidentally, the current implementation returns the correct result
because all default_ancestors values end with a "/", but it makes the
query slow. For a category with x ancestors and n characters in the
default_ancestors string, the database has to search for n categories
instead of just x+1. This gets worse the longer your category IDs are.


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


How reproducible:
Always

Steps to Reproduce:
1. Execute some code which uses getDefaultAncestors().
2. Take a look at the "default_ancestors in (...)" of the executed query.

    

Actual Results:  The "(...)" contains one string for every character
in the category's default_ancestors column.


Expected Results:  Only use strings which can actually match something
in the "(...)" list.


Additional info:

Comment 1 Vadim Nasardinov 2003-11-07 15:39:09 UTC
We need to merge the following change from the trunk onto the 6.0 tree:

Change 36775 by vadim@vadim-at-home on 2003/10/07 17:44:15

    Fixed some very sketchy logic that was responsible for populating
    the IN clause of a SQL filter.

    Before the change, the ancestor path of "2654/2653/" would result
    in the following list being used as the IN filter: [, 2, 26, 265,
    2654, 2654/, 2654/2, 2654/26, 2654/265, 2654/2653, 2654/2653/]

    After this change, the value of the list is computed as [, 2654/,
    2654/2653/]

Affected files ...

...
//core-platform/dev/src/com/arsdigita/categorization/Category.java#39 edit


Comment 2 Carsten Clasohm 2004-02-18 09:27:08 UTC
This change (36775) should be integrated into the 6.0 branch. One of
our clients is currently experiencing performance problems because of
the old getDefaultAncestors(). In fact, the query generated by the old
version is by far the one with the highest number of total block gets.

Comment 3 Carsten Clasohm 2004-02-18 10:03:15 UTC
You also may want to use changelist 40504 on top of 36775, which at
least on Oracle makes things a little faster by filtering on the
primary key instead of the default_ancestors column.


Comment 4 Carsten Clasohm 2006-07-12 09:03:25 UTC
Closing old tickets.