incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: ReferenceManager rewrite: seeking a little discussion
Date Fri, 19 Mar 2010 03:44:08 GMT
New RefManager code is done, and all tests pass. It works pretty
nicely, too. I'll check it in tomorrow morning.

Even better, I've been able to kill another dozen or more bugs, so
we've got just 2 remaining. Getting very close to a clean build...

Andrew

On Mon, Mar 15, 2010 at 9:00 AM, Andrew Jaquith
<andrew.r.jaquith@gmail.com> wrote:
>> 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 <andrew.r.jaquith@gmail.com> 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
>>>>>   *
>>>>
>>>>
>>
>>
>

Mime
View raw message