incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <te...@net-frame.com>
Subject Re: WikiPage constructors
Date Sat, 13 Dec 2008 15:25:45 GMT
I don't understand JCR, so I'm still wondering about the impact.  I'm
using Derby as the underlying DB (for JDBCPageProvider).  But, in
addition to the JSPWiki tables, I have quite a few other tables (and
databases) as well supported by the same DB.  Will the new JCR scheme
permit continued use of that DB (though through other interfaces), or
will the whole thing have to be ripped out? 

On Sat, 2008-12-13 at 14:18 +0200, Janne Jalkanen wrote:

> All and none.
> 
> The move to JCR means that your old database and JDBCProvider won't  
> work anymore.  You will need to migrate to a new DB (and it's still a  
> bit early to say how exactly this is going to be done - JDBCProvider  
> is not a core component, so someone needs to figure out a way to do  
> the migration.)
> 
> However, this particular change that is mentioned below has no impact  
> whatsoever.
> 
> /Janne
> 
> On Dec 11, 2008, at 03:03 , Terry Steichen wrote:
> 
> > Janne,
> >
> > What will be the impact on those of us that use JDBC-based pages?
> >
> > Terry
> >
> > On Thu, 2008-12-11 at 00:55 +0200, Janne Jalkanen wrote:
> >
> >> Folks,
> >>
> >> there is a minor problem with WikiPages and JCR.
> >>
> >> In the old days, the recommended pattern was to create a WikiPage
> >> with new WikiPage(WikiEngine,String).  The problem is that with JCR,
> >> this simply won't be possible, since the WikiPage ceases to be a
> >> passive retainer of information, and will actually store a reference
> >> to the JCR Node.  This has a couple of impacts:
> >>
> >> * WikiPages can no longer be cached (which wasn't a smart thing to do
> >> previously either, though some internal components did so, mostly to
> >> avoid hitting the repository.  Which won't of course be a problem in
> >> the future.)
> >> * WikiPages cannot be directly constructed anymore - instead,
> >> WikiPages will need to be fetched using WikiEngine.getPage() or
> >> created with WikiEngine.createPage().  Otherwise, the JCR Node
> >> reference would be null, and there would be a bunch of NPEs flying
> >> around the code.
> >> * WikiPages will not be thread-safe (though no guarantees were given
> >> previously either - they just happened to be)
> >>
> >> [In fact, that's exactly what it does right now, if you check my
> >> latest commits to the jcr branch.  We have used the new WikiPage() -
> >> idiom pretty liberally everywhere, and that is currently causing some
> >> pain.]
> >>
> >> Now, this change would not be without its merits - it would allow
> >> WikiPage to become an interface, and that is very nice (and almost
> >> mandatory) if we consider the fact that we would like to have a
> >> stable API.  Also, any trick I can think of around this problem
> >> either involves overloading WikiContext more, or creating a labyrinth
> >> of if( getNode() == null ) setNode( m_engine.getContentManager
> >> ().getSession(m_engine.getWikiContextFactory().newViewContext
> >> (null,null,this)).getRootNode().getNode(getName())) -calls in most of
> >> the WikiPage methods.  Which could be somewhat slow, and would also
> >> create two WikiContexts for each request...
> >>
> >> How do the fellow developers feel about this change?  Does this pose
> >> insurmountable problems for anyone, or change any plans?
> >>
> >> /Janne

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message