Enhancement #164

Support named paths

Added by Marc Dequènes almost 10 years ago. Updated almost 10 years ago.

LDAP :: Abstraction
Target version:
Start date:
Due date:
% Done:


Estimated time:
Patch Available:
Found in Versions:
Help Needed:


It would be useful to have names for paths, possibly with parameters, in order to avoid using DNs, and hide this complexity to the user. It would also help naming objects with the same characteristics but not the same place in the tree (like many organisationalUnit objects).

It would be nice to have absolute and relative paths. For example :
  • users -> ou=People,dc=milkypond,dc=org
  • own_domains => ou=Domains,...
  • spc_accounts -> ou=SpecialAccounts,...
    So we could create a new user in 'users', a new domain in 'individual/<user>:own_domains', a new special account in 'entity/<entity>:spc_accounts', ...

Nevertheless, 'users' is also 'unit/people', which is somewhat redondant, event if using an object name is not enough to get a unique path (as it is equivalent to a deep search which can give several results). So, we need to find a common solution.



Updated by Marc Dequènes almost 10 years ago

Let's say the first component is a search, and all other are just on step in the tree (so one could use 'root' as the search to do all the steps if needed). This way any path can be described, as long as all needed objects are declared. It would give examples like :
  • root:unit/People
  • individual/duck
  • individual/duck:unit/Domains:domain/
  • entity/hurdfr:unit/Domains:domain/
It is quite lenghty, so perhaps having ":" for one step and "::" for sub-search could help reduce. It would not ensure unicity in all cases, but may be sufficient. It would give:
  • individual/duck::domain/
  • entity/hurdfr::domain/
    (with maximum reduction depending on what is enforced-uniq at the database level, so 'domain/' and probably 'system_account/hf-wiki' may already be uniq in this case)

Updated by Marc Dequènes almost 10 years ago

With this method we can create new objects in a simpler way, without specifying the parent as an extra argument.

We also need to think about search results: what object name/path would be given back ?

Finding an object could be quite costly, but one-steps could allow calulating part of the final DN and simplify a bit. Handle customization, like proposed in #146, would probably cause problems.

Also available in: Atom PDF