Harry, thanks. You captured the spirit of what I'm trying to do much more simply than I did in my previous e-mail. :)
I did NOT suggest the more radical step of replacing the actual wiki page markup with UUIDs "under the covers" (and then de-referencing them for viewing and editing purposes). That's a discussion for another time. That WOULD address Florian's larger issue, combined with a consolidation of where and how we canonicalize and resolve page names. That, too, is a discussion for another time. :) Andrew On Sun, Mar 14, 2010 at 12:56 PM, Harry Metske <[email protected]> wrote: > Although I cannot completely oversee the consequences of this switch, I in > general like the idea of using internal numbers/names/labels (uuids in our > case) instead of external (visible) names for referencing purposes. > The issue is very similar to SQL tables, where it is much more convenient > using identity columns as unique keys instead of "name columns" , especially > when using foreign keys. > > I think this issue does not directly relate to external page names (as > Florian discussed). > > With the assumption that using UUIDs is only used internally, and not > showing up anywhere in the public API: > +1 from me, at least something to "commit and try" > > > regards, > Harry > > 2010/3/14 Andrew Jaquith <[email protected]> > >> 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 >> >
