[ApacheDS] [1.5.x] Timestamps and modifier names on schemaSubentry

[Alex Karasulu <ak...@apache.org>]

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:

    https://issues.apache.org/jira/browse/DIRSERVER-852

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:


http://cwiki.apache.org/confluence/display/DIRxSRVx11/Schema+Subsystem+Redesign

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.

Proposal
=====

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:

schemaModifiersName
schemaModifyTimestamp

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 1.3.6.1.4.1.1466.115.121.1.15{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.

Drawbacks
=======

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?

Alex