Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: bugzilla@apache.org
To: dev@cocoon.apache.org
Subject: DO NOT REPLY [Bug 31600]  -
    [PATCH] Caching support for XIncludes
Message-Id: <20050916032923.034C0149@ajax.apache.org>
Date: Fri, 16 Sep 2005 05:29:23 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31600>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31600


apache.bugs@lojjic.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|apache.bugs@lojjic.net      |


------- Additional Comments From apache.bugs@lojjic.net  2005-09-16 05:29 -------
(In reply to comment #4)
> But wouldn't that cause a cache-key clash if you had 2 different includes that
> called the same source but extracted different XPath subset? Ideally these 2
> results would both be cached separately.

It's difficult to explain this because pipeline caching is a very complex beast.

There's no key clash because the key returned by the individual included Source
is ignored; instead, each included source's Validity is requested and those are
aggregated into a MultiSourceValidity.  So instead of a bunch of key->validity
pairs for each included source, we have a single key->validity pair for the
whole transformer.

The key returned by XIncludeTransformer is always "XInclude", which at first
seems wrong but it actually works because this key->validity pair is never
stored individually.  Instead, it is used to build yet another key->validity
pair for the entire pipeline (or, more accurately, pipeline fragments so we can
get partial pipeline caching).  Therefore the final key is a combination of the
keys for all the components before the transformer, and "XInclude".

I think I went on a tangent there... the simple answer to your question is that
all we're worried about is the SourceValidity objects from the included sources,
as their keys are totally ignored in favor of the single key for the
transformer's aggregated validity.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.