On 25.10.2005 09:06, Bart Molenkamp wrote:
(Can it be discussed here, or do I need to add them as comments to the issue too?)
Of course.
I don't totally agree with your latest comment. The CacheValidity won't solve the problem, IMO it's a problem with the ID being generated that is not unique.
Yes, the non-unique ID is a problem as you can see with the issues described by Sarah. For her repeated calls to the same URI brought always the same fragment. Generating unique URIs solved the problem for her - but also switches off any caching.
In my case, the URI for a report is always the same, but the contents of that report is based on who is calling it. Multiple users can call the same URI, each resulting in different content.
How do you differentiate the user? The same way you have to do it for the cache key of the original XML, haven't you? This is why I thought it is just a matter of caching.
A cache validity won't solve this, there is just a need to store multiple fragments in the same store.
And where is the problem to generate different cache keys per user?
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.
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.
Jörg
