In the current setup, it is pretty much impossible to ever modify a schema to specify a new MUST attribute on an object. Once the schema is updated, replications of objects without the new MUST attribute cause breakage.
If it were possible to specify a default value for an attribute in the schema, this problem could be mitigated. Ideally, this default would accept not only static values (ex. 0, "sha1") but also would be extensible to support dynamic values (ex. timestamp, UUID).
Since this feature is limited by the oldest 389 version in the replication set, it is advantageous to land this feature as soon as possible.
Do you mean, specify the default value to use in the schema definition? I suppose that might be possible with a schema extension, but then schema replication would still break with older servers that did not know about how to process that new extension.
Replying to [comment:1 rmeggins]:
That is exactly why landing this feature as quickly as possible is advantageous. :)
Replying to [comment:2 npmccallum]:
Replying to [comment:1 rmeggins]: Do you mean, specify the default value to use in the schema definition? I suppose that might be possible with a schema extension, but then schema replication would still break with older servers that did not know about how to process that new extension. That is exactly why landing this feature as quickly as possible is advantageous. :)
That's going to be difficult, because in LDAP there is no concept of a "default value" as there is in SQL, so that (non-standard, I might add) mechanism will also have to be written from scratch, tested, etc.
I'm not so sure that we should add something non-standard like this to the schema. It would be possible to write a "default value" plug-in to do this sort of thing, but this isn't going to happen soon. Is this something that IPA really needs? If so, we can get it on the roadmap, but it wouldn't happen until 1.3.4 at the earliest I think.
Metadata Update from @npmccallum: - Issue set to the milestone: FUTURE
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to None - Issue close_status updated to: None - Issue tagged with: Schema
My understanding is that the ticket is about two different RFE not related.
Adding on a server a MUST attribute in an objectclass definition makes the definition more restrictive. Entries must have this attribute. In that sense this new definition is seen as a subset of the oc definition on the others servers. During replication subset definitions are overwrite by superset definitions. To allow the new definition (MUST) to be forced in the topology, schema should support an extra mechanism (like versioning) that would force a definition independently if it is subset or superset. This RFE is not planed at the moment.
Having default values for attribute is usually done with virtual attributes (cos, computed attribute) or real attibute (with plugins). WIth this RFE it requires a change in schema code to handle default value. Then during schema checking, if a missing mandatory attribute is detected pick the value from the schema and add it in the entry. It looks quite a significant change without a clear understanding of the benefit and justification.
These two requests are not planed, please reopen the ticket
Metadata Update from @tbordaz: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/1234
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.
Login to comment on this ticket.