tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Volker Lendecke]

On Sat, Apr 21, 2012 at 07:28:04AM +1000, Andrew Bartlett wrote:
> On Fri, 2012-04-20 at 16:08 +0200, Christian Ambach wrote:
> > > Agree. Lets break back compatibility.
> > > We need TDB2, but we need a the best TDB2 we can get.
> > > Lets not cripple it by imposing semantics or restrictions from the
> > > TDB1 API we want to break from.
> > >
> > > A new api, a new namespace, a new clean start.
> > 
> > I would push the patch early next week if there are not vetos.
> > It disables the building with TDB2 by default so we should not silently 
> > stumble across clashing APIs until the TDB2 API has been sorted out.
> > 
> > The adventurous can still enable it.
> > 
> > Hopefully Rusty picks this up again soon so we do not see too much 
> > bit-rot on TDB2 that in principle is a good idea, but the current 
> > implementation and integration seems to cause unnecessary grief.
> 
> Given that we have the proposal to move exclusively to TDB2, this seems
> like a bad idea, because once removed from autobuild it will quickly
> bitrot (and if it doesn't, what do we gain?  This thread started because
> tdb2 semantics were in Volker's way).  
> 
> Is there an urgency that means we must do this next week?  (I know there
> is a delay, but I would still like Rusty to have a say on this, unless
> there is a pressing urgent matter that means we must make a move on this
> now). 
> 
> I know that programming against two similar but not identical interfaces
> is a pain, but the work to make the code compatible with both has
> already been done.  (that is to not check against -1, and the other
> glue). 
> 
> We could change to only use tdb1 for the 4.0 release when we branch -
> that would have much less impact on our ability to move exclusively to
> tdb2 in the future.  However, we are clearly not near the branching
> point, and some folks want the features tdb2 brings in a 4.0 release.

If I understood the +1 series right we have pretty strong
votes to change the tdb2 API so that both the native tdb1
API without wrappers and the tdb2 API can be used
simultaneously in the same program. Christian's change would
mean that we can remove the wrapper code and the other
compat changes again.

The main two users that would benefit from tdb2 most are ldb
and dbwrap. Given a new tdb2 API, I would really like to
write a new dbwrap backend that uses the new API before 4.0.
All our central tdb's would immediately benefit from the new
library. ldb is also a central piece of code that has
modular backends already. A backend for tdb2 should be
relatively easy as well.

+1 on Christians change as a preparation for the tdb2 API
change.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de