No, the query cache only caches the primary keys. The first time it's
run all the objects are sent accross and each one is cached by primary
key. The set of primary keys returned for that query are also cached.
Then, the next time the same query is run, it issues a select for each
key in the cached set, with each one being a hit presuming the objects
haven't expired. If iterator does n+1 selects for the FIRST query,
that would be very bad. Most of the time you run a query only once and
I wouldn't want to do n+1 selects for each of those cases.
The more I think about this aproach the more I like it. I think it
would be nice to keep ListView as it is, but have PageableListView
delegate to an interface like this. And also, I don't think the
interface is too sparse. I typed that last response to quickly. The
PageableListView only needs to get results and the total. If you want
to support ordering, or anything else, you can do that directly on the
delegate.
One thing I would add though, would be a setPageableListView() method.
If the DataProvider knows about its container, it can do cleanup
things when it's underlying data changes (like a removeAll() when a
sort order or filter is added).
On 7/29/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > Yea, I can see how that would work. You're just saying to put
> > the "black box" in the ListView, right?
> There is no black box. The paging that the pagedlist does is no longer
> necessary.
>
> > Your DataProvider
> > interface is a bit too simple (doesn't allow ordering, and
> > EJB and Hibernate2 can't wrap an object in a model with only
> > the object itself for reference), but I think it could work
> > nicely with some fleshing out.
>
> I am working on example that does both of the above, here are some snippets:
>
> Sorting (I know its not generalized yet, just a working prototype)
>
> public class SortableContactDataProvider extends ContactDataProvider
> {
> private String sort; // <===== yes later this will be a list of
> sortparams
> public Iterator iterator(int first, int count)
> {
> return getContactsDB().find(first, count, sort).iterator();
> }
> public void setSort(String sort) {
> this.sort=sort;
> }
> public String getSort() {
> return sort;
> }
> }
>
> Model wrapping:
>
> public class DetachableContactModel extends AbstractReadOnlyDetachableModel
> {
> private long id;
> private transient Contact contact;
>
> protected ContactsDatabase getContactsDB() {
> return DatabaseLocator.getDatabase();
> }
>
> public DetachableContactModel(Contact c) {
> this(c.getId()); // <=========== here is the trick
> contact=c;
> }
>
> public DetachableContactModel(long id) {
> if (id==0) throw new IllegalArgumentException();
> this.id=id;
> }
>
> protected void onAttach()
> {
> if (contact==null) { // <======== no need to load if ctor
> with object used
> contact=getContactsDB().get(id);
> }
> }
>
> ...
> }
>
> > Returning an Iterator is very nice. If all you need to do is
> > iterate, there's no reason to require a List.
>
> What more can you do with a read-only list?
>
> > But because I'm
> > implementing a List, there's no way to incorporate that.
> > However, returning a list WILL use the cache, just not by
> > default. You have to set useQueryCache to true.
>
> I don't think that works the same way, I might be wrong though. If you set
> hibernate.use_query_cache=true and then set query.setCachable(true) you will
> cache the entire resultset which is not the same. When you call
> query.iterate() it uses n+1 queries to retrieve data, that means the first
> query gets all the primary keys, and then it retrieves the objects object by
> object (the other n queries) so you end up with each object being cached
> separately in the cache not as the entire resultset. This gives you a much
> higher cache-hit chance when retrieving multiple objects and when retrieving
> an object by pk.
>
> -Igor
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
