[MGNLSTK-690] Provide for sorting, filtering and shrinking by query in STKUtil Created: 21/Oct/10  Updated: 23/Jan/13  Resolved: 17/Dec/10

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: base system
Affects Version/s: None
Fix Version/s: 1.4

Type: Improvement Priority: Major
Reporter: Joerg von Frantzius Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File magnolia-module-standard-templating-kit.patch    
Issue Links:
dependency
depends upon MAGNOLIA-3331 Provide for maxResultSize in Query-API Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Testcase included:
Yes
Date of First Response:

 Description   

Currently any callers of info.magnolia.module.templatingkit.util.STKUtil.getContentListByTemplateName(Content, String) will have to implement sorting, filtering and shrinking of results in Java. This leads to intolerable perfomance when thousands of result objects must be processed in Java.

The provided patch extends some method signatures of STKUtil so a maxResultSize (for shrinking), andClause (for filtering) and orderByClause (for sorting) can be passed in. This will allow subclasses of AbstractListItemModel to perform sorting, filtering and shrinking via JCR query rather than in Java.

The provided patch requires the application of the patch previously provided in MAGNOLIA-3331.



 Comments   
Comment by Magnolia International [ 21/Oct/10 ]

Thanks ! SureFireModuleManager could go, afaiac, to magnolia-core/test; will review more closely when the patch gets applied - sounds like its just a different ModuleDescriptorLoader no?

Comment by Joerg von Frantzius [ 22/Oct/10 ]

I just realize that it's not possible to change the AbstractItemListModel class hierarchy to querying instead of Java processing, without potentially breaking existing code (outside of the STK). That's because either all of filtering, sorting and shrinking must happen by query, or none.

It's also not possible to order by query similar to what info.magnolia.module.templatingkit.util.STKDateContentUtil.sortDateContentList(List<Content>, String, String, Calendar) does with its defaultDate.

So I'll go for a new class hierarchy "AbstractQueryingItemListModel", which has

  • String getOrderByClause() and
  • String getAndClause()

instead of AbstractItemListModel's filter(List<Content> itemList) and sort(List<Content> itemList);

The resulting classes will be configuration-compatible to their original equivalents, so it should be easy to switch to the querying class counterparts in existing systems.

Comment by Joerg von Frantzius [ 26/Oct/10 ]

Result from discussing with Philipp:

  • existing class hierarchy will be kept
  • AbstractItemListModel methods filter() and sort() changed to not abstract (so new subclasses don't need to implement them), and instead implemented empty in AbstractItemListModel
  • new methods added to AbstractItemListModel:
    • protected String getFilterClause()
    • protected String getSortingClause()
  • AbstractItemListModel.search() changed to first query using getFilterClause(), getSortingClause() and getMaxResults(), and afterwards invoke filter() and sort()
    • this will keep API compatibility, i.e. for existing subclasses outside STK that have overridden these methods
    • only currently known problem: will break overridden filter() in subclasses when these filter less restrictive than the originally overridden filter() implementation
  • AbstractDateContentModel.sort(): will still sort in Java if defaultDate is not null, because there is no way to express that behaviour in a ORDER BY clause
Comment by Federico Grilli [ 03/Dec/10 ]

Hi Jörg, can this issue be considered resolved?

Comment by Joerg von Frantzius [ 03/Dec/10 ]

Hi Federico,

now that I look closely at the title of this issue I realize that indeed this one can be closed.

The changes to STKUtil are in place, but they are not yet used by any AbstractListeItemModel subclass. I'll simply open a new issue for that once I find the time to implement it.

Comment by Magnolia International [ 17/Dec/10 ]

Thanks for all the patches Jörg; indeed this issue is now resolved, it just got lost in the sea of other issues

Generated at Mon Feb 12 07:29:28 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.