On Mon, 2006-10-30 at 20:50 +1100, tridge@xxxxxxxxx wrote:
> > Honestly, to make things easy we should store by GUID, because otherwise
> > in handling renames you need a global lock and traverse each object to
> > make sure there aren't references to the renamed object.
> > Actually we do not check anything but sooner or later we need.
> That would have horrible performance for our most common cases.
> > At the same time storing by DN is a big performance advantage. So in the
> > end I think that being able to have 2 keys for the same record could be
> > the best way (GUID and DN) so that references will be stored by GUID
> > (and searches for the GUID will be equally fast) but all other
> > operations will use the normalized DN as key.
> no, having 2 keys for every record is a terrible idea. It means that
> every add/delete has to update at minimum two things, where we
> currently update one.
If this is made inside ldb_tdb I think we can make it fats enough.
Or we decide to store by GUID only when told, so that for local LDBs we
don't incur into this penalty.
> Renames are _rare_. It doesn't matter if they are hard to code, as
> long as they are possible to code (and it is certainly possible!).
Well, consider a person that drags 100 users from an OU to another.
And consider updating 5000 groups 100 times ...
Samba Team GPL Compliance Officer