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: JavaDB/Apache Derby as a WikiPageProvider?
Date Tue, 14 Oct 2008 14:25:19 GMT
Murray,

The original, somewhat experimental JDBCPageProvider was initially
upgraded in mid-2005.  I participated in this upgrade - the package had
the name 'forthgo' in it.  I also modified it to use Derby (this is
where the Derby-specific quirks came in).  Somewhere around mid-2006
JDBCPageProvider was largely rewritten.  I took a look at the rewrite
and thought it was a better internal approach.  

But I had also developed a flexible access module (based loosely on the
JDBCPageProvider code) that my application uses to create pools of JDBC
connections as needed and have made extensive use of that module for
supporting four different databases and numerous (sixteen, I think)
tables using the same underlying Derby.  Naturally, I ended up 'sneaking
under the API' to access the WikiPage tables directly to do some special
analysis, so to accommodate the rewrite, I'd have to have modified those
routines.

Being lazy and firmly of the belief that 'if it ain't broke, don't fix
it' I stuck with the version I've been using, and am still using it
(with JSPWiki version 2.6.2).  Current page count for the site is 5,389,
which it seems to handle just fine (so far, anyway).

Terry



On Wed, 2008-10-15 at 01:47 +1300, Murray Altheim wrote:

> Terry Steichen wrote:
> > Murray,
> > 
> > I use Derby (I think it's version 10.1.3.1)  to implement
> > JDBCPageProvider (though not the latest version).  A few quirks to get
> > started, but basically have no complaints on its performance.
> 
> Hi Terry,
> 
> Is this the code found at http://jdbcprovider.berlios.de/? Or
> are you referring to a different JDBCPageProvider? Not that I've
> been following along on that but I thought that project was
> basically stagnant (e.g., last release was March 2007). Mikkel
> Troest in the Help mailing list writes:
>  >
>  > 2008-Aug-24 21:02
>  > Hi Jonathan,
>  >
>  > I'm afraid JDBCProvider does not work with JSPWiki 2.6.
>  > Something in the page API changed, and JDBCProvider has not
>  > been updated to support the new API.
>  >
>  > I think I heard that the JSPWiki dev team is looking into
>  > using JCR (Apache JackRabbit) as backend for some future
>  > release of JSPWiki. This will actually obsolete the
>  > JDBCProvider project, since JCR can be configured to use
>  > an RDBMS as a back-end in turn.
>  >
>  > Personally, I do not have the time to research the current
>  > JSPWiki page API, and I think the other JDBCProvider
>  > developers are at least as busy with their day jobs as I am.
>  > My best advise, then, is for you to ask on the JSPWiki
>  > users list what the status for the JCR integration is.
>  > If it's several releases in the future, I might help you
>  > out by cooking up a release of JDBCProvider that works with
>  > the current JSPWiki. There doesn't seem to be that much
>  > demand for it, though.
> 
> But good to hear that Derby seems like a good fit otherwise...
> given that Janne has started heating up the Priha frying pan
> I might try cracking a few eggs. I was originally thinking of
> writing a BerkeleyDB JE backend for Priha but a JavaDB one
> might be even better, esp. if there'd be no need for Berkeley.
> 
> Thanks,
> 
> Murray
> 
> ...........................................................................
> Murray Altheim <murray07 at altheim.com>                           ===  = =
> http://www.altheim.com/murray/                                     = =  ===
> SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =
> 
>        Boundless wind and moon - the eye within eyes,
>        Inexhaustible heaven and earth - the light beyond light,
>        The willow dark, the flower bright - ten thousand houses,
>        Knock at any door - there's one who will respond.
>                                        -- The Blue Cliff Record

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