Bug 109397 - ancestorsList in Category.getDefaultAncestors()
ancestorsList in Category.getDefaultAncestors()
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: ccm-bugs-list
Depends On:
Blocks: 108447
  Show dependency treegraph
Reported: 2003-11-07 09:12 EST by Carsten Clasohm
Modified: 2007-04-18 12:59 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-12 05:03:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Carsten Clasohm 2003-11-07 09:12:01 EST
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:

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 10:39:09 EST
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/,

Affected files ...

//core-platform/dev/src/com/arsdigita/categorization/Category.java#39 edit
Comment 2 Carsten Clasohm 2004-02-18 04:27:08 EST
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 05:03:15 EST
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 05:03:25 EDT
Closing old tickets.

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