incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Sun, 14 Mar 2010 20:45:44 GMT
> I'm basically +1 on using UUIDs internally, *BUT* there are two big problems: performance.
*If* ReferenceManager stores only UUIDs, every single page view causes a session.getNodeByUUID().getProperty("wiki:title"),
which is two reads to the database *per reference*.  This will kill the idea of including
the page references on the page itself, which I think is really neat.

Yes, that is right. I am running into this issue right now. :)

As for references "on the page itself," did you mean the page markup?
I haven't changed that... that still stays as WikiNames. What I meant
was using UUIDs in the wiki:refersTo and wiki:referredBy attributes.

> So to solve this a UUID => wiki:title cache needs to be put somewhere.

Should be pretty straightforward, no? The only time cache entries
would need to be refreshed would be on page-rename operations, which
won't happen too often.

> Now, the second big problem is non-existing references.  Since an UUID can only exist
when the page in question exists, you can't use UUIDs to track references to non-existing
pages (which the ReferenceManager also tracks).

You can, if you use dummy pages to represent the non-existent pages; I
mentioned this in my first message on this subject (earlier today).
These go in wiki:references/wiki:notCreated. When new pages are added,
we look in the "uncreated" tree first, and if there, we move the node
to the pages tree (and then save all the other attributes on top of
the node as we normally would).

> So you need to track both in possibly separate systems, including all the page creations
and removals.  This is the reason why I've never bothered to rewrite ReferenceManager into
using UUIDs, since doing this tracking has been a bit too much work, especially considering
that it works now and has no performance problems in 3.0.

You are right about having to create a separate mechanism for tracking
uncreated nodes, and that is what I am experimenting with. I'm
reasonably far along in terms of proof-of-concent. But, I would
slightly disagree that the current "use page names as pointers"
strategy for ReferenceManager works. It mostly does, but breaks down
in rename situations. I found it nearly impossible to debug -- which
is saying something, considering I did the last RefMgr rewrite.

This is all about where you want to do the extra work: (1) during page
renames (as we do now), or (2) during page creation and deletion (as
the UUID strategy would require). But the UUID strategy has some nice
benefits, such as making ReferenceManager's code simpler -- it was
insanely hard to debug. Now it's just difficult.

So, what do you think? I still think this is worth pursing... and I'm
nearly finished with a POC.


> On 14 Mar 2010, at 20:33, Kalle Kivimaa wrote:
>> Andrew Jaquith <> writes:
>>> 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.
>> We basically did this in the company I work for, where we use JSPWiki as
>> a base for our UI. We ran into problems with the reference manager
>> taking up a *very* long time at wiki startup, so we switched over to
>> using a SQL database for page storage and storing the links between
>> pages in the database, thus eliminating the "recreate the link
>> information at every startup" problem.
>> The problems we've had with this approach have been mostly on the "how
>> to keep the link information correct", so that's probably something you
>> want to keep in mind.
>> --
>> * Sufficiently advanced magic is indistinguishable from technology (T.P)  *
>> *           PGP public key available @        

View raw message