Well, you'll need to let me no offline what it means. ;)
On Mon, Mar 16, 2009 at 3:00 AM, Janne Jalkanen <[email protected]> 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 > >
