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 Sat, 20 Mar 2010 09:42:16 GMT
very nice !

thanks,
Harry

2010/3/19 Andrew Jaquith <andrew.r.jaquith@gmail.com>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message