> -----Oorspronkelijk bericht----- > Van: Joerg Heinicke [mailto:[EMAIL PROTECTED] > > On 25.10.2005 09:06, Bart Molenkamp wrote: >
... > > Besides that I think that caching is done at the pipeline level: if > > the generator, transformers and the serializer indicate that the cache > > is valid, then the cached content will be returned and in that content > > of course the link to the extracted fragment - but the fragment isn't > > extracted again. > > FragmentExtractorTransformer and FragmentExtractorGenerator are sitemap > components, so where is the problem? > > > So I think that it is just as simple as to generate an unique ID. > > Maybe some UUID, maybe something with a SecureRandom (like how > > continuation IDs are generated). Also, I suggested to move this ID > > generation to a protected method, so that users can override that method > > in the transformer and implement their own method to generate an ID > > (won't break the current way that the extractor is working). > > UUIDs won't solve the problem as they remove any caching as described > above or in the bug report. > Sorry, but I still don't understand why this breaks caching. The UUID (or whatever ID) generated for the fragment is IMO independent from the cache key. When the pipeline indicates that it's valid, then the cached content (with the generated UUID in it) will be returned, and the UUID won't change, and the same fragment will be looked up from the transient store. But, I also believe that the cache key can solve the problem, and I can see if I can fix this bug using the cache key. Do you need the key from the generator generating the XML in this case? How can this be looked up? And is there a possibility that this key is already used in the store? > The protected method can solve the problem, but IMO it should be > possible to solve it once for all use cases, not individually by every > user. Well, in that case one can always overwrite the method if needed (so I think that this will be a good idea), but I also think that most users (if not all) shouldn't have to worry about this. Bart.
