incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <janne.jalka...@ecyrd.com>
Subject Re: WikiPage.equals()
Date Mon, 16 Mar 2009 07:00:24 GMT

The problem was that CachingProvider used equals() to check whether a  
WikiPage was already in the cache.  Unfortunately, since WikiPage used  
to be a container for attributes, so you could conceivably have two  
WikiPages with the same name and version, yet different attributes.  
This would cause dataloss in certain cases.

Now that mapping wikipages and attributes together is done by the back- 
end (and WikiPage itself is just a facade), I think your analysis is  
correct. The reason why the tests are failing is probably because the  
backend is quite liberal in creating new WikiPage objects as opposed  
to caching them (CachingProvider used to make sure that there's  
*usually* just one copy of a WikiPage around, but it could never be  
sure :-)

Always find any statement with "per se" very funny (it is a Finnish  
vulgarity ;-)

/Janne

On 16 Mar 2009, at 06:13, Andrew Jaquith wrote:

> In the 3.0 SVN, bunches of unit tests, like assertEquals( wikiPage,
> context.getPage() ), aren't working any more because
> JCRWikiPage.equals() doesn't really have a contract per se. It seems
> to me that two JCRWikiPages ought to be considered equal when their
> JCR paths and versions are the same. Note that the hashCode() method
> incorporates the m_name (WikiName) and version fields, so that would
> seem to imply that would be the correct test for equality.
>
> Janne, what do you think?
>
> -- Andrew


Mime
View raw message