[Fedora-directory-users] Virtual DIT views vs hierarchicalDIT

[Pete Rowley]

> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com 
> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf 
> Of Jeff Clowser
> Sent: Friday, June 24, 2005 1:17 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Virtual DIT views vs 
> hierarchicalDIT
> 
> Pete Rowley wrote:
> 
> > Which sounds like a nice enhancement, redirect non-view 
> entry creation 
> > to
> >
> >some other part of the dit :)  I think it is only the creation case 
> >that really matters - clients that just do modify ops are much more 
> >likely to use the dn of the returned entry than to try to 
> construct one 
> >(apps that do that would be very broken in any case).
> >  
> >
> Well...  Personally, I think administrative apps that create 
> entries need to know the "real" DIT.  I'm not sure how safe 
> it would be to try to translate a view backwards (is it 
> always safe/easy to translate back to the "right" place?)  If 
> you write DN based attributes (owner, manager, uniquemember) 
> based on a view instead of the real tree, seems like a lot of 
> ugliness can happen.

It certainly isn't simple problem and many cases need to be factored in.
Though much of this can be simplified by observing or predicting what
clients really do as opposed to what they might do.  Taking your example, it
is possible that an application might be fooled if it first creates an entry
in a view and then immediately uses the (view based) dn to populate
attributes in other entries.  Probably the more typical case is to retrieve
an existing entry from a view and then use the dn of that to populate the
attributes of other entries, which should just work (assuming we have the
currently absent create support).

It _should_ be relatively simple for the server to translate back and forth
between DN's (the translation is always one way, from view based to target),
so it would be possible even to correct for attribute values, but I have my
doubts about performance for such things - certainly for returned search
results anyway.  So, having said this, I am not convinced it is a good thing
to try either.

On the real dit versus view based: if a view based dit works and acts
exactly the same way (assuming no issues) as a real dit, does it really
matter whether the admin client knows about it?  After all, the "real" dit
isn't real either, it's really a "view" of what we store in the db.