-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Friday, July 29, 2005 9:59 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] lists
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
