WikiPage.equals()

[Andrew Jaquith <an...@gmail.com>]

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

Re: WikiPage.equals()

[Andrew Jaquith <an...@gmail.com>]

Well, you'll need to let me no offline what it means. ;)

On Mon, Mar 16, 2009 at 3:00 AM, Janne Jalkanen
<ja...@ecyrd.com> wrote:
>
> 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
>
>

Re: WikiPage.equals()

[Janne Jalkanen <ja...@ecyrd.com>]

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