tdb_chainlock() in tdb1, tdb2 and tdb_compat ?
ambi at samba.org
Thu May 10 05:46:08 MDT 2012
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.
So my proposal would be to:
1. leave libtdb as it is today
1a) make tdb the default again in the build
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?
3. create a dbwrap_tdb2 layer that will take care of the subtle changes
in a single place for source3
3a) switch source3 code place by place to the new dbwrap, start with the
ones that will benefit from tdb2 first
4. adopt the source4 pieces (I am not familiar with those)
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.
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.
More information about the samba-technical