Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 91675 invoked from network); 12 Feb 2004 09:44:10 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 12 Feb 2004 09:44:10 -0000 Received: (qmail 14622 invoked by uid 500); 12 Feb 2004 09:43:35 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 14607 invoked by uid 500); 12 Feb 2004 09:43:35 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: users@cocoon.apache.org Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 14585 invoked from network); 12 Feb 2004 09:43:34 -0000 Received: from unknown (HELO SATURN.tvnz.co.nz) (202.36.33.202) by daedalus.apache.org with SMTP; 12 Feb 2004 09:43:34 -0000 Received: from akxch01.tvnz.co.nz ([172.26.42.39]) by mail01.tvnz.co.nz with trend_isnt_name_B; Thu, 12 Feb 2004 22:43:58 +1300 Received: from akxch03.tvnz.co.nz ([172.26.80.24]) by akxch01.tvnz.co.nz with Microsoft SMTPSVC(5.0.2195.6713); Thu, 12 Feb 2004 22:43:44 +1300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F14C.1598C62C" Subject: Using getTransfomerValidity with a source based key for cache invalidating Date: Thu, 12 Feb 2004 22:39:17 +1300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using getTransfomerValidity with a source based key for cache invalidating Thread-Index: AcPxTBV4Aj5Jy2WoTZ+kMFkPi870fg== From: "Corin Moss" To: X-OriginalArrivalTime: 12 Feb 2004 09:43:44.0962 (UTC) FILETIME=[B4CC9220:01C3F14C] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C3F14C.1598C62C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Guys, I've been implementing the external cache validity functionality of DBPrism, and I've decided that I want to externally invalidate my transformers as well. I can see that getValidity within (for example) TraxTransformer will be fairly easy to implement with an external validity, but what I'd also like to do is create a key based on values contained within the input source for the transformation. In this case a series of record ids. I can't rely on a hash, as I need to be able to selectively clear the cache given a single valid id. As far as I can tell, TraxTranformer's getKey method uses the URI of the inputSource as the basis for a key (including params of course.) Has anyone tried modifying this to analyse the _content_ of the input document? And if you have, do you have any tips for me? I have a horrible feeling that the performance cost of analysing the input document is going to be greater than the gains ;) I can easily write some xpath to concatenate all record ids within an input document, and then clear the cache based on any one of those ideas, but I'm sure there's a smarter idea :) I'd appreciate any feedback you may have. Thanks, Corin. Corin Moss Lead Developer TVNZ Interactive +64 9 916 7367 +64 21 403 054 corin.moss@tvnz.co.nz ------_=_NextPart_001_01C3F14C.1598C62C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Using getTransfomerValidity with a source based key for cache = invalidating

Hi Guys,

I've been implementing the external = cache validity functionality of DBPrism, and I've decided that I want to = externally invalidate my transformers as well.  I can see that = getValidity within (for example) TraxTransformer will be fairly easy to = implement with an external validity, but what I'd also like to do is = create a key based on values contained within the input source for the = transformation.   In this case a series of record ids.  I = can't rely on a hash, as I need to be able to selectively clear the = cache given a single valid id.

As far as I can tell, TraxTranformer's = getKey method uses the URI of the inputSource as the basis for a key = (including params of course.)  Has anyone tried modifying this to = analyse the _content_ of the input document? And if you have, do you = have any tips for me?  I have a horrible feeling that the = performance cost of analysing the input document is going to be greater = than the gains ;)  I can easily write some xpath to concatenate all = record ids within an input document, and then clear the cache based on = any one of those ideas, but I'm sure there's a smarter idea = :)

I'd appreciate any feedback you may = have.

Thanks,

Corin.



Corin Moss
Lead Developer
TVNZ Interactive

+64 9 916 7367
+64 21 403 054
corin.moss@tvnz.co.nz



------_=_NextPart_001_01C3F14C.1598C62C--