Incomplete/cached list

[Stephen Kestle]

I'm working on some task-based software, and want to maintain views of the tasks for easy querying - enter Glazed Lists.
The problem I'm facing:

• Task lists are relatively transient (e.g. once complete, they are only retained for auditing/reporting purposes)
• The persistence layer is pluggable (might be a database/hibernate, but currently is a different type of store)
• The current implementation is a cache of tasks by id, and run an arbitrarily complex query to determine what id's should be returned (tasks link to other information via universal identifiers, so building a task object may query multiple systems)

So, I need to:

1. Lazily build the backing list by the view requests
2. Update the backing list as appropriate for the requested views
3. Automatically dispose list views via same sort of cache-like algorithm

1 and 2 I'm thinking will already be supplied, or easily possible, but the last... is this something I'd need to write myself?

Is this the right thing:

1. Have an CachedEventList that is essentially a cached list (something that will indicate when something is being removed due to cache expiry/size constraints)
2. ... referenced by a ListViewCache where lists can be retrieved by matchers:
1. If it exists, then return the list view
2. otherwise, Request it from the CachedEventList, which will ensure full population
3. If the CachedEventList purges a task (expiry/size constraints), the ListViewCache (as a listener of the CachedEventList) will dispose the appropriate views.  A brute force implementation could iterate through all the ListViewCache's keyed matchers to see if they match the purged task...

Has this been done before? Is it the right direction to head in?

Thanks heaps for an awesome idea/implementation...

Stephen

[James Lemieux]

Hey Stephen,

   GL does really ship with a good caching list. Most transformations only make sense when all of the data is actually present and can be acted on, so a cached list runs counter to this assumption.

   If reasonable behaviours can be made for sorting partially available data, or filtering, etc, then you can most likely make your own caching list without too much trouble.

   As an FYI, we have an EventList that uses Hibernate to keep its backing store in sync, so you may want to mine that if it applies.

   Disposing "views" of your task data will require effort on your part to reference count too, methinks. Unfortunately GL pipelines use hard references, and thus will prevent themselves from being GC'd until some external authority can dispose() the parts of the pipeline that won't be needed.

  Overall, you'll definitely have to get your hands dirty to get what you are describing.

James

On Wed, May 27, 2009 at 4:23 PM, Stephen Kestle <stephen.kestle@...> wrote:

I'm working on some task-based software, and want to maintain views of the tasks for easy querying - enter Glazed Lists.
The problem I'm facing:

• Task lists are relatively transient (e.g. once complete, they are only retained for auditing/reporting purposes)
• The persistence layer is pluggable (might be a database/hibernate, but currently is a different type of store)
• The current implementation is a cache of tasks by id, and run an arbitrarily complex query to determine what id's should be returned (tasks link to other information via universal identifiers, so building a task object may query multiple systems)

So, I need to:

1. Lazily build the backing list by the view requests
2. Update the backing list as appropriate for the requested views
3. Automatically dispose list views via same sort of cache-like algorithm

1 and 2 I'm thinking will already be supplied, or easily possible, but the last... is this something I'd need to write myself?

Is this the right thing:

1. Have an CachedEventList that is essentially a cached list (something that will indicate when something is being removed due to cache expiry/size constraints)
2. ... referenced by a ListViewCache where lists can be retrieved by matchers:
1. If it exists, then return the list view
2. otherwise, Request it from the CachedEventList, which will ensure full population
3. If the CachedEventList purges a task (expiry/size constraints), the ListViewCache (as a listener of the CachedEventList) will dispose the appropriate views.  A brute force implementation could iterate through all the ListViewCache's keyed matchers to see if they match the purged task...

Has this been done before? Is it the right direction to head in?

Thanks heaps for an awesome idea/implementation...

Stephen