JSPWiki 3.0 already stores the references internally in the page repository, so
that's solved.
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.
Putting the page references only on PageInfo does not work either, since in a
public wiki the PageInfo will get spidered anyway.
So to solve this a UUID => wiki:title cache needs to be put somewhere.
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). 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.
/Janne
On 14 Mar 2010, at 20:33, Kalle Kivimaa wrote:
> Andrew Jaquith <[email protected]> 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 @ http://www.iki.fi/killer *
