optional criteria-based data/count fetching

Joseph Marques jmarques at redhat.com
Mon Dec 13 16:21:35 UTC 2010


commit 8e313057f12a8ecdb379c32b70f0daa99cceb223
Author: Joseph Marques<joseph at redhat.com>
Date:   Tue Dec 7 01:43:12 2010 -0500

     strategy to allow more efficient criteria-based query generation&  execution

     * can now call Criteria.setRestriction(Restriction) to bypass generation
       and execution of either the data-query or the count-query.  this reduces
       processing and eliminates one round trip to the database each time the
       given criteria is used to fetch.

-----

You can now easily specify in any criteria-based SLSB method whether you want to return the page of data, the cardinality of the non-paged result (e.g., count / totalsize), or both (the classic semantics).  Why is this useful?  Well, take for example the "X recent alerts" message you see in the application footer.  In this case, all we need is the count of the alerts generated by any resource visible to the user over the last 8 hours, so we can use the count restriction:

    AlertCriteria criteria = new AlertCriteria();
    criteria.addFilterStartTime(System.currentTimeMillis() - (1000L * 60 * 60 * 8));
    criteria.setRestriction(Restriction.COUNT_ONLY);
    GWTServiceLookup.getAlertService().findAlertsByCriteria(criteria, AsyncCallback);

Under the covers, only the count-query will be generated (ever so slightly less load on the app server) and executed (less load on the DB, especially as the complexity of the generated query increases...and one less DB roundtrip).  In a similar fashion, I can specify that I only care about the data by setting Restriction.COLLECTION_ONLY, which would skip generating/executing the count-query.  This would be useful if you want to:

* fetching the entire collection - assumption is a small collection where all elements should necessarily be shown, such as the list of measurement schedules for a given resource.
* selecting a specific object (such as addFilterId) - assumption is count won't be used in this case, because all you really want is the single object, such as Resource{Group}DetailView objects
* searching and restricting the result set - assumption is that you only want to show the first 20-30 results, and don't care about the count because you're not dropping the data into a table that needs to know how many total objects there are to properly render pagination controls such as a vertical scrollbar

So please use criteria restrictions where it makes sense.



More information about the rhq-devel mailing list