Hi all,

I've been thinking about fixing the issue we have with the creatorsName, modifiersName, createTimestamp and modifiersTimestamp for the schemaSubentry in ApacheDS 1.5.x.

As you may already know in 1.0.x the schema is static and so the server's startup time is used for both timestamps and the admin DN is used for the modifier and creator's names.  This is acceptable for a static schema however in the dynamic schema we need to accurately publish this operational attributes to reflect the changes taking place on the schema so clients can respond to schema changes.  BTW there is an issue in JIRA for this problem here:


I opened up this thread to discuss possible solutions.  If anyone wants a refresher on how the schema subsystem is structured please see the following documentation on it:


Note that we have not implemented the separate SAAs just yet.  First we want to get a dynamic schema operational for the entire DIT served then we can look into separate schemas for different regions of the DIT. 


Presently the schemaSubentry located at cn=schema is completely virtual (generated on the fly from the schema registries in the server) and it contains attributes which store the schema entity descriptions for the server.  The problem we have is to accurately publish the following attributes to reflects schema changes:

  o creatorsName
  o createTimestamp
  o modifiersName
  o modifyTimestamp

The first two are really easy.  The creatorsName will always be the administrator's DN: uid=admin,ou=system.  The creatorsTimestamp should be the creatorsName on the ou=schema entry.  The rational is this virtual entry is valid at the point the schema subsystem was created.  This timestamp will reflect the time when the server was last built as it should since this is when the default schema is created.  It's natural to use the admin user for the creatorsName attribute.

The modifiersName and modifyTimestamp are not that easy.  Any time there is a change under ou=schema these fields need to be modified and persisted.  So storing them in the virtual entry is not an option since these values must persist across server restarts.  I'm thinking best way to store this information would be to use a special entry under the ou=schema namingContext to store the following attributes:


It's tempting to store more information here in this entry like the schema entity or the schema that is modified however a schema operation may modify more than one schema entity perhaps in multiple schemas.  And a modify operation may perform different kinds of operations on the each of the modified schema entities and this is far too much to track in a single entry.  So it's not worth while tracking this information here but in a change log implemented for this purpose at a later date. 

So let's keep it simple and do just what we have to do with this special entry.  The entry can have it's own objectClass and a simple cn for it's RDN attribute.  Here's what I propose for the schema of this entry:

attributetype ( TBD NAME 'schemaModifyTimestamp'
    DESC 'time which schema was modified'
    SUP modifyTimestamp )

attributetype ( TBD NAME 'schemaModifiersName'
    DESC 'the DN of the modifier of the schema'
    SUP modifiersName )

attributetype ( TBD NAME 'subschemaSubentryName'
    DESC 'the DN of the schema subentry this modification information corresponds to'
    EQUALITY distinguishedNameMatch
    SYNTAX{32768} )

objectclass ( TBD NAME 'schemaModificationAttributes'
        DESC 'a special entry tracking schema modification attributes'
        SUP top STRUCTURAL
        MUST ( cn $ subschemaSubentryName $ schemaModifyTimestamp $ schemaModifiersName ) )

The reason why I use attributes besides modifiersName and modifyTimestamp is to prevent collisions between these injected attributes for the entry itself.  Secondly looking for these attributes will also return the other schema schema related attributes since they extend modifiersName and modifyTimestamp respectively.

Any change to the schema entity entries under the ou=schema namingContext will update these schema specific operational attributes as well.  When the schema subentry is read these values will be read and populated into the virtual schema subentry dynamically by the schema service.  This will lead to the desired effect of correctly informing clients of changes to the global schema.

Note the schemaSubentryName corresponds to the DN of the subentry that these modification attributes correspond to.  For our present purposes this will be cn=schema for now until we introduce multiple SAAs.  More is discussed about this attribute in the drawback section below.  Basically this attribute is here for extension purposes when more than one SAA exists.


When/If we introduce the application of different schemas to different regions of the DIT via Schema Autonomous Areas (SAAs) then we have a problem.  At this point the server needs to determine which schemas are in each SAA and appropriately update the modification attributes for the last change to only those schemas included in the SAA.  Essentially there will be more than one schema subentry for each SAA.  In this case the added schemaSubentryName attribute may come in handy and this is the reason I added it to the schemaModificationAttributes objectClass.  This way a different set of schema modification attributes can be maintained for each schema subentry corresponding to each SAA and the global schema space.

Logic will need to be added to update each of these schemaModificationAttributes separately depending on the applicability of the schema changes based on the schema in effect for the different corresponding SAAs.  For now I will handle updates just for the global schema space. 

Thoughts? Comments?