ZK Huge Grouping Model"
Robertwenzel (talk | contribs) |
Robertwenzel (talk | contribs) |
||
Line 83: | Line 83: | ||
/** | /** | ||
* This method will count a lot and return a constant value as long as data does not change, | * This method will count a lot and return a constant value as long as data does not change, | ||
− | + | * so caching would be desirable | |
* @return | * @return | ||
*/ | */ | ||
Line 92: | Line 92: | ||
/** | /** | ||
* This method will be called quite often with recurring parameters, | * This method will be called quite often with recurring parameters, | ||
− | + | * so caching (of most frequently used params) would be desirable !!! | |
* @return the childrenCount between 2 groups... (including groupIndexFrom and excluding groupIndexTo) | * @return the childrenCount between 2 groups... (including groupIndexFrom and excluding groupIndexTo) | ||
*/ | */ |
Revision as of 10:03, 1 August 2013
Robert Wenzel, Engineer, Potix Corporation
August, 2013
ZK 6.5 (or later)
Introduction
bla bla you have some big data... how to display
article already handles display big data in a flat list http://books.zkoss.org/wiki/Small_Talks/2009/July/Handling_huge_data_using_ZK
based on the concepts (paging at DB level, separate paging control from grid) there how to do grouping...
The challenges
grouping is a powerful feature in ZK but also adds an extra layer of complexity
paging and grouping challenges
1. groups can be open or closed (also interactively)
- -> the total count and the number of pages changes, when opening/closing nodes... (needs efficient counting, and state keeping)
2. groups can have arbitrary number of children
- -> random access to a specific page ... how to know the current group and position inside the group for that page
- --> implement a feaseable search
3. minimize DB operations (accumulating network/DB latency)
- -> caching vs. memory consumption
1. + 2. + 3. !!!! combining all three in an efficient, memory preserving way
limitations... needs to store the state in memory (humans are limited, so one is unlikely to toggle 100+ groups)
Maxing out what is possible... ZK GroupsModel supports int indexes so go up to Integer.MAX_VALUE (~ 2.000.000.000 records)
not unrealistic -> Hibernate have changed their paging api to long already...
Implementation
Accessing the data
not use DB, just deterministic random value... caching the group sizes in memory e.g. 400.000.000 of groups child counts stored in an int[] are still 160 MB of memory
Data Record and Dao
package org.zkoss.grouping.dao;
import java.util.Date;
public class AccessDataRecord {
private String ipAddress;
private String browser;
private long contentLength;
private String country;
private Date accessTime;
private String url;
//... Constructor + getters
package org.zkoss.grouping.dao;
public class AccessLogDao {
public int getGroupCount() {
//your DB query to count the groups
}
public List<GroupInfo<String, String>> getGroupInfos(int startIndex, int pageSize) {
//your DB query and mapping to create GroupInfos for this page of groups
}
public List<AccessDataRecord> getChildInfos(int groupIndex, int startIndex, int pageSize) {
//your DB query and load this page of children in the group
}
/**
* This method will count a lot and return a constant value as long as data does not change,
* so caching would be desirable
* @return
*/
public int getTotalChildCount() {
//your DB impl to calc the total number of children
}
/**
* This method will be called quite often with recurring parameters,
* so caching (of most frequently used params) would be desirable !!!
* @return the childrenCount between 2 groups... (including groupIndexFrom and excluding groupIndexTo)
*/
public int getChildCountBetween(int groupIndexFrom, int groupIndexTo) {
//your DB impl to calc the number of children between 2 groups
}
The Paging Model
package org.zkoss.grouping;
import java.util.List;
import org.zkoss.grouping.dao.AccessLogDao;
import org.zkoss.grouping.dao.AccessDataRecord;
import org.zkoss.grouping.model.GroupInfo;
import org.zkoss.grouping.model.PagingGroupsModel;
import org.zkoss.grouping.model.search.BinaryGroupingPositionSearch;
import org.zkoss.grouping.model.search.GroupingPositionSearch;
class AccessDataGroupsModel extends
PagingGroupsModel<AccessDataRecord, String, String> {
private AccessLogDao groupsDao;
public AccessDataGroupsModel(AccessLogDao groupsDao, int pageSize, boolean initialOpen, boolean hasGroupfoot) {
super(pageSize, initialOpen, hasGroupfoot);
this.groupsDao = groupsDao;
setPositionSearch(binarySearch());
}
@Override
protected int loadGroupCount() {
return groupsDao.getGroupCount();
}
@Override
protected List<GroupInfo<String, String>> loadGroupPage(int startIndex, int pageSize) {
return groupsDao.getGroupInfos(startIndex, pageSize);
}
@Override
protected List<AccessDataRecord> loadChildrenPage(int groupIndex, int startIndex, int pageSize) {
return groupsDao.getChildInfos(groupIndex, startIndex, pageSize);
}
@Override
protected int getTotalChildCount() {
return groupsDao.getTotalChildCount();
}
private GroupingPositionSearch binarySearch() {
return new BinaryGroupingPositionSearch(this, 4096) {
@Override
protected int getChildCountBetween(int groupIndexFrom, int groupIndexTo) {
return groupsDao.getChildCountBetween(groupIndexFrom, groupIndexTo);
}
};
}
}
Counting & State keeping
Random Access Paging
Appendix
Download
Comments
Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License. |