Bug 118313 - Category#getDefaultAscendants should not add an order to the query
Summary: Category#getDefaultAscendants should not add an order to the query
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Vadim Nasardinov
QA Contact: Jon Orris
Depends On:
Blocks: 113496
TreeView+ depends on / blocked
Reported: 2004-03-15 15:32 UTC by Daniel Berrange
Modified: 2007-04-18 17:04 UTC (History)
0 users

Clone Of:
Last Closed: 2004-04-06 14:40:02 UTC

Attachments (Terms of Use)

Description Daniel Berrange 2004-03-15 15:32:41 UTC
Description of problem:

The method:

    public CategoryCollection getDefaultAscendants() {

Explicitly adds an ordering based on 'defaultAncestors' before
returning the CategoryCollection. This is bogus, since the method has
no means of knowing what the caller will be doing with the collection
& thus whether this ordering is applicable. 

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

How reproducible:

Steps to Reproduce:
1. Call cat.getAscendants()
2. Add order based on title
3. Iterate over results
Actual results:
Results are ordered by ancestors

Expected results:
Results are ordered by title

Additional info:

Comment 1 Vadim Nasardinov 2004-03-15 17:18:28 UTC
Dan, I have a quick question.

I agree that Category#getDefaultAscendants() should add an order
clause to the returned CategoryCollection.  While it's easy to remove
the offending line of code, we have a small amount of code that seems
to expect the returned collection to be ordered by default_ancestors.

These clients are

    public static String getCategoryPath(Category)


   public Collection getParentCategories(String purposeKey)

(The latter is irrelevant and is list only for the sake of completeness.)

There is also //cms/dev/src/com/arsdigita/cms/ui/item/Summary.java,
but I can't tell from a cursory look whether it makes any assumptions
about the ordering of the collection returned by getDefaultAncestors.

Do you think it would be sufficient to fix the above two known uses of
getDefaultAncestors such they explicitly add the ordering they
require?  Is it ok not to worry about other unknown uses of
getDefaultAncestors that may or may not rely on the (undocumented)
fact that the returned collection is currently ordered?

Comment 2 Daniel Berrange 2004-03-15 17:23:21 UTC
Yes, lets just move the existing ordering into these 3 places which
need it. Since we've not officially released this API yet we don't
have to care about breaking other peoples code here ;-) I'll check
APLAWS codebase too.


Comment 3 Vadim Nasardinov 2004-03-15 19:24:47 UTC
Fixed on the trunk in change 41366.

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