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 >>
