very nice ! thanks, Harry
2010/3/19 Andrew Jaquith <[email protected]> > 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 > <[email protected]> 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 <[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 > >>>>> * > >>>> > >>>> > >> > >> > > >
