| f4f307e7cfb86d9e677f1cfce11161c278fbd736 6940 |
|
30-May-2011 |
ludo |
Fix issue OPENDJ-126 - Bad syntax for lastChangeNumber, firstChangeNumber, and lastExternalChangelogCookie.
firstChangeNumber and lastChangeNumber are now Integer, single valued.
The lastExternalChangelogCookie is an opaque set of bytes. I agree it looks like a string, but it would be better handled as opaque, thus an OCTET STRING. I'm marking it SINGLE-VALUE though. |
| 1867ab6b86dfc4bb06682075c0713b8b18b2c522 1562 |
|
03-Apr-2007 |
neil_a_wilson |
Add initial support for a virtual attribute subsystem, and implement a few
different kinds of virtual attributes. This commit addresses the following
issues:
- Issue #1475 -- General virtual attribute support
- Issue #539 -- Support for the isMemberOf virtual attribute
- Issue #544 -- Support for the entryDN virtual attribute
- Issue #1056 -- Support for the subschemaSubentry virtual attribute
- Issue #85 -- Support for the real attributes only control
- Issue #86 -- Support for the virutal attributes only control
In general, virtual attribute support consists of three parts:
- An implementation of the org.opends.server.api.VirtualAttributeProvider
class, which provides the logic for actually generating the values, providing
support for various kinds of matching, and potentially the ability to process
search operations involving the virtual attribute that might not otherwise be
indexed.
- The org.opends.server.types.VirtualAttribute class, which is a subclass of
org.opends.server.types.Attribute and uses the virtual attribute provider to
generate its values.
- The org.opends.server.types.VirtualAttributeRule class, which associates a
virtual attribute provider with a given attribute type, and also with a set
of criteria that controls which entries should have the attribute.
The virtual attribute rule currently supports the following criteria that can
be used to decide whether an entry should have a given virtual attribute:
- Zero or more base DNs. If any base DNs are provided, then any entry which
falls below one of those base DNs will be a candidate to get the virtual
attribute. If no base DNs are provided, then DIT location will not be taken
into account when determining eligibility.
- Zero or more group DNs. If any group DNs are provided, then any entry that
belongs to one of the specified groups will be a candidate to get the virtual
attribute. If no group DNs are provided, then group membership will not be
taken into account when determining eligibility.
- Zero or more search filters. If any filters are provided, then any entry
that matches one of the specified filters will be a candidate to get the
virtual attribute. If no filters are provided, then the contents of the
entry will not be taken into account when determining eligibility.
In addition to that criteria, virtual attribute rules define a conflict
behavior, which controls how to behave when the entry already has one or more
real values for the attribute. The conflict behavior can be
"real-overrides-virtual" (to only show the real values),
"virtual-overrides-real" (to only show the virtual values), or
"merge-real-and-virtual" (to show both real and virtual values).
The virtual attribute implementation has been designed so that there should be
virtually no performance impact unless the attribute needs to be returned to
the client or it is referenced in a search filter, and you can completely
disable virtual attributes if you don't need them. |
| 1b71d2770489cdb8f8d7a38eb4c6e5720253280b 1036 |
|
25-Jan-2007 |
neil_a_wilson |
Make a number of updates to schema processing, all of which fall under the
umbrella of issue #1163. The individual issues addressed include:
* 1139 -- Properly handle OBSOLETE flag in schema elements. The OBSOLETE flag
is now recognized when processing matching rules, attribute types, object
classes, name forms, DIT content rules, DIT structure rules, and matching rule
uses. It essentially provides a way to "deprecate" a schema element so that
existing data that makes use of them will still be treated properly, but the
server will not allow newly-created elements to reference them.
* 1145 -- Consider updating X-ORIGIN to reference newer RFCs. When the schema
configuration files were originally written, there were a number of references
to RFC 2252 and RFC 2256 that were updated in RFC 4512 and RFC 4519, among
others. The X-ORIGIN extension for each element in the 00-core.ldif schema
configuration file should now reference the latest specification that contains
that element.
* 1146 -- Consider enforcing object class inheritance restrictions. The server
will now ensure that abstract classes can only inherit from other abstract
classes, that auxiliary classes can only inherit from abstract classes and
other auxiliary classes, and that structural classes can only inherit from
abstract classes and other structural classes. Further, all structural object
classes must include the "top" abstract class as the root of their inheritance
chain.
* 1147 -- Consider enforcing attribute type inheritance restrictions. The
server will now ensure that a subordinate attribute type will have the same
usage as its superior type. Further, the server will enforce that a
subordinate attribute type may be collective if and only if its superior type
is collective. Due to the subjective nature of the "refinement" clause for
syntax inheritance, no check will be made regarding the syntax relationship
between a superior and subordinate attribute type.
* 1151 -- DIT content rule validation isn't handled correctly. The server will
now allow attribute types to appear in an entry if they are included in the
required or optional attribute type lists for a DIT content rule even if those
attributes are not allowed by any of the entry's associated object classes.
Further, the DIT content rule validation process will now ensure that none of
the prohibited attribute types are required by the structural object class or
any of the allowed auxiliary object classes.
* 1158 -- Attribute syntaxes describing schema elements aren't strict enough.
Previously, in most cases that one schema element referenced another element
that was not defined (e.g., an object class allows an attribute type that is
not defined in the server schema), the server would ignore the unresolved
dependency. The server will now fail to validate schema elements that depend
on other schema elements which are not defined in the server schema.
Similarly, there were cases in which the server did not properly validate that
an object class was of the appropriate type (e.g., for a DIT content rule,
there was no check to ensure that the structural object class was actually
declared structural, or that all of the allowed auxiliary objectclasses were
actually declared auxiliary). The server will also fail to validate schema
elements with these kinds of problems.
* 1159 -- Incomplete attribute type usage constraints. The server did not
properly ensure that COLLECTIVE attribute types had a usage of
userApplications, and that NO-USER-MODIFICATION attribute types had an
operational usage.
* 1164 -- Need more complete DIT structure rule validation. The server did not
properly ensure that if an entry's parent was associated with a DIT structure
rule, that entry would only be valid if it was covered by a DIT structure rule
which listed the parent's DIT structure rule as a superior rule.
* 1165 -- Consider reduced name form and DIT structure rule checking. The
server would often perform more schema validation than necessary for most types
of operations. In particular, name form and DIT structure rule validation
should not be required for modify operations, and DIT structure rule validation
should also not be required for LDIF import operations since we cannot
guarantee that the parent will be accessible. |
| 09e99ece4a4f3104ed2e7023372499ff8754be3d 945 |
|
09-Jan-2007 |
neil_a_wilson |
Update the schema backend to provide full support for online schema updates.
which includes the following:
- It is now possible to add attribute types, objectclasses, name forms, DIT
content rules, DIT structure rules, and matching rule uses. Adding a schema
element that is already present but with a different definition will replace
that element.
- It is now also possible to remove existing attribute types, objectclasses,
name forms, DIT content rules, DIT structure rules, and matching rule uses.
If the element is removed and then re-added, then it is treated as adding the
element with a a different definition (i.e., replacing the existing
definition).
- If an existing schema element is replaced or removed, then the update will be
made in the schema file that contains that definition. If a new attribute
type is added and is not manually associated with a schema file, then the
server will use a default schema file of 99-user.ldif. The schema file to
use can be manually overridden using the X-SCHEMA-FILE extension.
- A significant amount of effort has been put into understanding dependencies
between various schema elements and ensuring that those dependencies will be
resolved correctly, and will also be updated whenever a dependent element is
updated.
- Note that the equality matching rule for the attributeTypes, objectClasses,
nameForms, matchingRules, matchingRuleUse, ditContentRules, and
ditStructureRules attribute types has been changed to the caseIgnoreMatch
rule. This does deviate from the standard somewhat, but allows the server to
provide notably better performance while still exhibiting correct behavior as
far as clients are concerned.
OpenDS Issue Number: 366 |
| e983228258e4740043573622af5672efb926dfed 629 |
|
23-Oct-2006 |
neil_a_wilson |
Add the nsUniqueId operational attribute to the OpenDS schema. We don't
intend to use it, but it can help provide compatibility with the Sun Java
System Directory Server, as that server includes the nsUniqueId attribute when
performing LDIF exports.
OpenDS Issue Number: 853 |
| 82ddfcdf60dd1c0d7a7f3bf4826c1d3c52083681 628 |
|
23-Oct-2006 |
neil_a_wilson |
Update the groupOfNames objectclass to make the member attribute optional, and
update the groupOfUniqueNames objectclass to make the uniqueMember attribute
optional. This varies from the standard definition in RFC 4519, but it makes
more sense for them to be optional. It provides better compatibility with the
Sun Java System Directory Server, and it greatly simplifies problems like how
to handle an attempt to delete a user account if referential integrity is
enabled and that user is the last remaining member in a group.
OpenDS Issue Number: 619 |