Bug 118313
| Summary: | Category#getDefaultAscendants should not add an order to the query | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Web Application Framework | Reporter: | Daniel Berrangé <berrange> |
| Component: | other | Assignee: | Vadim Nasardinov <vnasardinov> |
| Status: | CLOSED RAWHIDE | QA Contact: | Jon Orris <jorris> |
| Severity: | high | 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: | 2004-04-06 14:40:02 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: | 113496 | ||
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
//cms/dev/src/com/arsdigita/cms/ui/CategoryForm.java
public static String getCategoryPath(Category)
//cms/dev/src/com/arsdigita/cms/ui/authoring/ItemCategorySummary.java
generateXML
//core-platform/dev/src/com/arsdigita/categorization/CategorizedObject.java
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?
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. Fixed on the trunk in change 41366. |
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: Always 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: