Re: back-sql View instead of real table (ITS#805)

[mitya@seismic.geol.msu.ru]

jerry@pbs.com wrote:

> Full_Name: Jerry Amundson
> Version: 2.0.4
> OS: Solaris 2.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (207.108.74.2)
>
> http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/back-sql/docs/concept?rev=1.1.2.2&hideattic=1&sortbydate=0
>
> In the last paragraph of section 2 in the "concept" file, above, there is
> reference
> to "something like this:", but there is nothing after it.
>

Sorry, that commit was done in a hurry, I probably missed that phrase ;)
Will commit changes soon.

>
> This sounds like what I'm trying to implement - I would like to eliminate the
> need
> for the 'ldap_entries' table as it requires extra database administration, and
> is
> mostly duplication (except dn) of what I already have in SQL Server tables.

That depends on your needs. As I've already figured out from correspondence, there's often no need for complex hierarchy, and
people make views to achieve simple one from the data they have .  I found this message from Robin Elfrink, it may well help
you before I manage to change documentation:

Robin Elfrink wrote:
>
> This is what I did:
>
> create view ldap_entries (id, dn, oc_map_id, parent, keyval) as
>         select userid, UPPER(CONCAT(CONCAT('cn=',gecos),',o=My
> Company,c=NL')), 1, 0, userid from unixusers;
>
> create view ldap_referrals (entry_id, url) as
>         select userid, gecos from unixusers;
>
> create view ldap_entry_objclasses (entry_id, oc_name) as
>         select userid, 'posixAccount' from unixusers;

DK> ok, I suppose I'll just add this as advice in documentation for those that
DK> don't want complicated hierarchy...

sorry didn't do it yet... In fact, Robin suggested one more improvement (substitution of metavars like $IP$ in queries), but
for lack of time it also didn't make further than todo so far ...

WBW, Dmitry