> ReferenceManager... Also, since RefMgr worked in 2.x line even in renames,
> I always figured that there was a small bug introduced, which means that
> debugging that one would've been easier than a full rewrite.
Yeah, though I re-wote it for 3.x by necessity, so it's going to have
bugs 2.x didn't have. :)
> (It should be noted that you will need to track the non-existent references
> using page titles. You can't do them based on UUIDs, since the UUIDs are
> assigned by JCR. You could create a dummy page, but that means littering
Yes, that's what I assumed.
> JSPWiki, so you need to build in certain sanity checks. In the end, there
> will be lots more code, though arguably it is going to be easier to debug.)
Noted. :)
>
> /Janne
>
> On Mar 14, 2010, at 22:45 , Andrew Jaquith wrote:
>
>>> 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.
>>
>> Andrew
>>
>>>
>>> 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
>>>> *
>>>
>>>
>
>
