i'm wondering if we shouldn't leave the existing listview stuff alone
altogether and instead start
a new db-centric CollectionView that can handle all this new stuff. one
thing i keep running
into with hibernate is that i want to view Sets instead of lists. a
DatabaseCollectionView
could be tuned to database-specific issues like the things you guys are
bringing up.
Phil Kulak wrote:
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Ìk
_______________________________________________
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
