incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Sun, 14 Mar 2010 16:56:38 GMT
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 <andrew.r.jaquith@gmail.com>

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message