You got it right except for the last point. If anything, it makes the code slightly simpler in most respects -- it cuts down the amount of code by about 10% in ReferenceManager, notably in the renaming code.
As for the broader issue you are raising, see the reply I just sent to Harry. Andrew On Sun, Mar 14, 2010 at 1:35 PM, Florian Holeczek <[email protected]> wrote: > Hi Andrew, > > thanks for the clarification! Indeed, I have misunderstood you. I must > confess that I don't know the code well enough to judge which impacts > your particular change may have. That said, I change my -1 to a 0. > > But if I understand you correctly this time, the whole thing now sounds > to me as follows: > * your change is no solution to the problem I meant (a pity! ;-) ) > * I think the problems you're addressing with it have their root cause > in the problem I mean > * So this would basically be a hack which makes the code more > complicated in order to fix some unit tests? ;-) > > Regards > Florian > > Am 14.03.2010 17:50, schrieb Andrew Jaquith: >> Hi Florian -- >> >> Thanks for your message. Why the -1? Trying to understand the nature >> of your objection. >> >> I should have clarified something in my previous message. The UUIDs >> are only used by ReferenceManager -- they are not exposed in the UI at >> all, and the public methods in ReferenceManager (e.g., getReferredBy) >> still return WikiPaths like they always have. Users won't see anything >> different, and they can still enter wiki names as they always have. >> >> Behind the scenes, the UUIDs are stored in the back-end JCR pages as >> wiki:referenceTo and wiki:refererredBy properties. Whenever the page >> is saved, we extract out the page names that are referenced (as we >> normally do), normalize the page name, figure out the UUIDs, and then >> stash the UUIDs. >> >> So, in case it wasn't clear -- this UUID stuff is all under the covers. >> >> Does that make you reconsider your -1? ;) >> >> Andrew >> >> On Sun, Mar 14, 2010 at 12:40 PM, Florian Holeczek <[email protected]> >> wrote: >>> Hi Andrew, >>> >>> we've known this issue for quite a long time already, haven't we? >>> I've been trying to put the focus on it several times (search the list >>> for normalization, page name, wiki name). Happy to see that this is >>> finally recognized as a real problem before 3.0 release :-) >>> >>> My opinion in short: Introducing and using UUIDs is certainly the >>> standard and well-proven way to solve such a problem in information >>> science. However, we're building a wiki server and the wiki way is using >>> wiki names as identifiers. My opinion was and is that we need to >>> normalize wiki names, which means to think about a mathematical function >>> (probably surjective) to map a given wiki name to one defined page. >>> Unfortunately, this may mean that we're breaking links by removing the >>> fuzzy logic we've been using up to now. >>> >>> So basically, a -1 from me for the UUID solution. >>> >>> Regards >>> Florian >>> >>> >>> Am 14.03.2010 16:29, schrieb Andrew Jaquith: >>>> All (and especially Janne) -- >>>> >>>> In digging into some of the remaining bugs clustered in >>>> PageRenamerTest, I was forced to confront what I'd coded up during the >>>> last re-write of ReferenceManager. Lots of the PageRenamerTests are >>>> still broken. The problem with page-renaming relates, I suspect, to a >>>> checkin Janne did previously that sought to handle case-sensitivity >>>> filesystem issues. To put it simply, the relationship between the wiki >>>> path (as stored in the JCRWikiPage ATTR_TITLE attribute) and the >>>> filesystem wasn't being dealt with gracefully by ReferenceManager. The >>>> bug was too complex to track down, and I didn't have the patience and >>>> time to do it. >>>> >>>> I don't mean to blame Janne for this -- not at all. It merely sheds >>>> light on the difficulty of keeping references when the identifiers are >>>> page names. When the page name changes, we have to jump through lots >>>> of hoops to keep the references intact. You can blame ME for that. It >>>> reminded me of the old saying "programmers will create the most >>>> complex things they can debug". >>>> >>>> In thinking this through a bit more, I thought it might be better if >>>> we stored references as UUIDs. This means (for example) that renaming >>>> is simple -- all we really need to just change the page text, rather >>>> than the reference "pointers". So, that's what I've been experimenting >>>> with. It seems to work really, really well, and the code is simpler. >>>> >>>> The only odd case we have to deal with is when we're referring to a >>>> page that hasn't been created yet. In that case, what I've chosen to >>>> do is create dummy pages in a separate JCR branch (part of the >>>> /jspwiki/wiki:references node tree). Then, when pages are added in >>>> ContentManager, we check FIRST to see if that page is in the >>>> "not-created" tree. If it is, we MOVE it to the pages tree and then >>>> save as normal. Deletions work in reverse: if the page has any inbound >>>> references, we move it back to the "not created" tree to ensure that >>>> references from live pages stay intact; otherwise we zorch the page as >>>> normal. >>>> >>>> The "not created" page tree, by the way, is also an example of >>>> something I'm calling a "page foundry" -- a place where future pages >>>> are born but not yet moved into production. I can imagine other >>>> foundries -- for example, a per-user foundry for drafts. Maybe >>>> "nursery" is a better metaphor, but you get the idea. >>>> >>>> Thoughts? The code isn't quite ready, but it is progressing nicely. We >>>> might as well fix it before the 3.0 release, right? >>>> >>>> Andrew >>> >
