tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Rusty Russell]

On Thu, 10 May 2012 13:46:08 +0200, Christian Ambach <ambi at samba.org> wrote:
> On 05/10/2012 07:08 AM, Rusty Russell wrote:
> 
>  > Since the transition is taking longer than we'd hope (and turning tdb2
>  > off again as proposed by Christian isn't going to help), perhaps we
>  > should change this and rename everything to tdb2*.  It's not *that*
>  > big a change to SAMBA in practice.
> 
> But what about outside users of libtdb? There seem to be various 
> projects that rely on libtdb. If we now change the semantics behind the 
> existing API, those projects will have to adjust their code as well.
> We will have to support libtdb for a while for all of the projects 
> depending on it until they have adopted to the TDB2 API.

Of course, but that maintenance burden is minimal, and one I'm quite
happy to carry.  If there are any TDB1 issues, they need to be fixed in
the tdb1 code inside TDB2, too.

> So my proposal would be to:
> 1. leave libtdb as it is today
> 1a) make tdb the default again in the build

Disagree with 1a, but I think people are a bit confused.  We're
currently talking about using tdb1 (the on-disk format), via the tdb2
code.  The switch to the tdb2 on-disk format is a separate step.

> 2. introduce tdb2 as new library with the new API
> 2a) add it to the autoconf build
> 2b) maybe leave out the tdb_compat part?

I'm working on 2a.  But you can't do it without tdb_compat: how will you
support tdb1 vs tdb2 everywhere?

> 3. create a dbwrap_tdb2 layer that will take care of the subtle changes 
> in a single place for source3

It already exists, we call that tdb_compat.  It was easier to audit the
entire SAMBA codebase for cases where semantics were different, than to
write a complete semantically correct tdb1-style wrapper.

I thought about it, but we'd need to audit callers later anyway.

> 3a) switch source3 code place by place to the new dbwrap, start with the 
> ones that will benefit from tdb2 first

source3 is already converted to using tdb_compat.

> 4. adopt the source4 pieces (I am not familiar with those)

That, too, is already done.

> 5. make tdb2 the default in the build
> 
> And then piece by piece migrate existing code to use tdb2 and once all 
> references have been removed, we'll need to encourage other projects to 
> follow our approach.

You can't migrate in pieces, really: you need to use tdb1 or tdb2.

> I am not sure how to handle CTDB here: once source3 starts to explicitly 
> request TDB2, CTDB will have to learn about it as well but we still need 
> a fallback that can deal with tdb1 databases until databases are 
> recreated after a complete cluster restart.

Yes, Amitay has been working on CTDB tdb2 integration.  As you say, it
only becomes an issue when we actually start writing tdb2 files.

Cheers,
Rusty.