multi-indexed tdb

[simo]

On Sat, 2006-08-12 at 23:23 +0200, Volker Lendecke wrote:
> On Sat, Aug 12, 2006 at 03:34:24PM -0400, simo wrote:
> > As Tridge already pointed out, ldb depends only on talloc and tdb, if
> > you copy out the 3 directories ldb, talloc, tdb from /source/lib and
> > place them somewhere else, you will have a standalone ldb build, all you
> > have to do is to cd in ldb and do: ./autogen.sh; ./configure; make
> 
> Did you try exactly those steps? For me it fails because it
> can not find popt.h:

Yes I did exactly these steps, as I do always to ensure ldb standalone
is not dependent on samba4 code.

> vlendec at delphin:/data/4_0/lib/ldb> make
> Compiling tools/ldbadd.c
> In file included from tools/ldbadd.c:37: ../ldb/tools/cmdline.h:25:18: error: popt.h: Datei oder Verzeichnis nicht gefunden
> make: *** [tools/ldbadd.o] Fehler 1

Right, we depend on popt for ldb, actually.
But samba3 has popt as well.

> > Why don't you expect it? Have you ever asked if anybody was interested?
> > I am interested, and I am more than happy to make the ldb library
> > compatible with C++. 
> 
> Sorry, but Samba4 does not even compile on all build farm
> hosts that just compile C. Samba4 deliberately uses struct
> names that conflict with function names, and it uses
> state->private a lot. "private" is a keyword in C++. That's
> a looong way to go.

I've changed exactly this thing on the code I could my hands on so far.
And I usually change it in any piece of code I put my hands on.
Ldb in fact doesn't have any structure or variable named "private".

> > And which are these goals? Have you asked what are the goals of the
> > people working on samba4 or more specifically on ldb?
> 
> Samba4 is a pure research project, Samba3 is production
> code. Don't get me wrong, I very much appreciate the work
> you are doing, we all benefit a lot from it. But it is so
> far away from production code that I would not consider it
> anywhere stable.

I think that this is not a fair consideration, actually I think that
some parts of samba are very much stable, and samba4 in general has a
very extended test suite. But I won't debate over sensations and taste.

> > > Or would the Samba4 developers be willing to separate out
> > > the non-modular ldb part? Is that even possible?
> > 
> > I will tell you if you explain me what dos it mean "separate out the
> > non-modular ldb part", I do not understand what it really means.
> 
> We don't need fancy stuff, we only need a multi-key
> database. No mapping of attributes, no auto-generated
> attributes, no server side sorting, nothing like that. Just
> multi-key. And maybe multi-index for aliases. That's it. If
> I copy all of lib/ldb as proposed I get tons of stuff I do
> not need.

And you will not use them unless you do that on purpose.
The bare ldb without modules does not have any fancy stuff you named
here.
It is modular exactly because this way you get _only_ what you need.
If you do  not need a module you just don't name it on the command line
or don't put it in the special @MODULES object.

> > Who is responsible when something breaks in samba3?
> 
> The one who checks the stuff in. Just look at the Samba4
> build farm. Nobody is responsible for that in Samba4 land.

This simply untrue, as I said we are not yet bothering with non-Linux
platforms, but the Samba4 code always build in the platforms we use.
And usually it doe not break because you are required to run make test
before committing.

> The fact that Samba4 is Linux only is very well displayed by
> the fact that tdb_firstkey/tdb_nextkey in Samba4-tdb (now in
> Samba3) broke on *ALL* non-Linux hosts when actually being
> excercised. And nobody so far bothered to port my fix to 4,
> even although I explicitly pointed out that the fix might
> also be interesting for Samba4.
> 
> > talloc_steal() will not go away from ldb, as it is part of the way ldb
> > has been thought from scratch, especially since we use a completely
> > async interface.
> 
> talloc_steal is made for people smarter than all of us
> working on Samba3 are.

No, it just require to use different coding standards.

> Every time I used talloc_steal in Samba3 I had to think
> hard to get it right. This is not a good sign for long-term
> maintainability. Tricky code sooner or later gets broken,
> and complex talloc hierarchies lead to very subtle code.

And this happens because at some levels mixing the old style samba3 code
with a hierarchical based one without clear separation or constraints is
not the right thing to do. You cannot drop in talloc in a portion of
code that use a lot of global or stack allocated structures, and does
not have a clear hierarchical memory model. I agree in fact that in most
samba3 code talloc_steal should not be used, or should be used with
extreme care.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org