Re: (ITS#6531) Modify updateref to generate referrals on the backend

[hyc@symas.com]

Rein Tollevik wrote:
> On 04/25/2010 12:49 AM, hyc@symas.com wrote:
>
>> Also in terms of logical abstraction the current behavior is wrong; the
>> frontend should of course generate the default_referral responses but
>> updateref is a per-backend item and should be generated at the backend layer.
>> Ideally this would all have been fixed to behave correctly by moving all
>> replication support into an overlay, where it properly belongs. As an interim
>> step it would be trivial to write an updateref overlay that supersedes the
>> current updateref behavior.
>
> Updateref processing should imo be kept out of any replication modules,
> it is needed in databases where syncrepl isn't configured too.  I'm
> using it on my subordinate databases (with an artificial updatedn so
> that slapd accepts it..) when syncrepl is configured on the superior
> glue database without managing all of the subordinate databases.  I.e,
> the infamous test058...
>
> I was having the same "chain only on some of the databases" requirement
> and is using a patch that allows it. I consider this patch more of a
> hack than a correct solution, which is why I haven't contributed it.  A
> separate updateref overlay apear to me as the best solution.  But for
> what it's worth, my patch is now in:
>
>    ftp://ftp.openldap.org/incoming/rein-ITS6531.patch
>
> An advantage with this patch over a new overlay is that it should be
> usable without any configuration changes (provided the chain overlay
> have already been configured in the databases and found to not work as
> expected there that is ... ;-).

I didn't quite follow the intended usage for this patch. Are other overlays 
expected to override the default over_mod_ref() handler?

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/