At the moment schema is a set of ldif files, containing a single entry with all the definitions. Replication of the schema is done with schema learning and eventually schema push.
It could be interesting to make cn=schema a true suffix with a subtree containing the definitions. Replicating the schema suffix could make help to for: getting rid of obsolete definitions, solve schema learning merge ability (the latest definition csn wins).
It would rely on the robust replication and make the schema life cycle easier to anticipated
N/A
cn=schema is a single entry containing all defs
cn=schema is a true suffix
We can keep root entry for compatibility reason but when all versions are running with cn=schema we will delete the definitions from there.
The schema would look like
dn: cn=schema ... attributetypes: ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 X-ORIGIN 'RFC 4519' ) ... dn:cn=postalAddress,cn=attributetypes,cn=schema objectclass: attributetype type: postalAddress syntax: postal_Address matchruleeq: caseIgnoreListMatch matchrulesub: caseIgnoreListSubstringsMatch matchrulecmp: caseIgnoreListCompare origin: RFC 4519 version: 1.1
Metadata Update from @tbordaz: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
Metadata Update from @mreynolds: - Issue priority set to: critical - Issue set to the milestone: 1.4.5
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/4158
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)