Idea

Say Coke+claim count is configured by:

claim_count+*right+*structure (type = CachedSearch?):

type:Claim
right_plus:[Company, refer_to: _self]
return: count

(somewhere between ruby and js :) )

When we save that card, that updates an entry in a global "cache_clear" hash.  The key is the rule name (claim_count+*right+*structure), the value is some sort of CacheClear object, which has three key parts:

1. the test(s) of whether cached items need repopulating

Based on the WQL, Wagn automatically contructs a test as to whether the current change is one that should cause an update.  It is run on every card change.

To frame this a bit, there are really two main kinds of changes we'd be looking at: changes to the Claim card itself (create, delete, or type update) or changes to the +Company card (basically any change matters, though a type update is admittedly debatable).  Technically renaming the Company or Claim card could break things, too, but I'm not going to deal with that here.

So we have two main tests cases;

• type==Claim && type_changed?   ## and optionally a test to see if it's a create, detele, or type update
• junction? && right_name=='Company' && left.type_id == ClaimID

The first one is a fairly obvious translation of the WQL.  The second starts from the perspective of the inner query and works its way out.

If either test passes it should return the +company card.  Otherwise it should return false.

2. the list of cached items to repopulate

In this case, what we need to do is figure out everything referred to by the +company card (both old and new versions if its content is getting updated)

At this point, we take the rule's set (claim count+*right) and use the referees (companies) as anchors and reconstruct, for example, Coke+claim count.  This list is kept somewhere in the main action of the act  until the "extend" phase, at which point...

3. repopulate cached items

We go through each item on the list and (re)populate it by running the structured search.  Unlike most structured cards, the content of the card itself matters here, because we use, eg Coke+claim_count to store the value of the count.  I suspect we want to skip all the history handling (act/action/change) on these cards because the history of caches is not particularly worth the performance hit.

~~~~~

I'm not actually entirely sure #2 and #3 will require any special configuration.  Might be able to do the whole thing with a Proc rather than this CacheClear object.