Having worked on the simple / practical way of getting collective attributes, my next task is to investigate and possibly fix ? the more complex but ultimately more complete, collective attribute scheme, which is used when you declare an object in the schema with COLLECTIVE (eg. in collective.schema).

So far, i have worked out how to create a collective definition, but it has no effect as i'm presuming subtreeSpecification is currently unimplemented. Can somebody please check i have the below correct at least.

I have declared the following :

dn: cn=template1,o=openldap,c=AU
objectClass: collectiveAttributeSubentry
objectClass: subentry
objectClass: top
cn: template1
subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }
createTimestamp: 20080906145020Z
creatorsName: cn=Manager,c=AU
entryCSN: 20080906145740.998417Z#000000#000#000000
entryDN: cn=template1,o=openldap,c=AU
entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8
hasSubordinates: FALSE
modifiersName: cn=Manager,c=AU
modifyTimestamp: 20080906145740Z
structuralObjectClass: subentry
subschemaSubentry: cn=Subschema

This appears to set up the collective attributes, and where they should apply but has no effect. Presumably this is because c-PostalAddress and/or c-PostalCode (as defined in collective.schema) are not present.

Well there are no suplimentary objectclases that allow these attributes, so i tried adding the extensibleObject objectclass, and then added the c-PostalCode and c-PostalAddress attributes. This gave me :

dn: cn=template1,o=openldap,c=AU
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
objectClass: subentry
objectClass: top
cn: template1
subtreeSpecification: { base "ou=test1,o=openldap,c=AU" }
c-PostalAddress: 123 Someplace St
c-PostalCode: 9999
createTimestamp: 20080906145020Z
creatorsName: cn=Manager,c=AU
entryCSN: 20080906145740.998417Z#000000#000#000000
entryDN: cn=template1,o=openldap,c=AU
entryUUID: df2317c6-106e-102d-82e5-ffce2194e1a8
hasSubordinates: FALSE
modifiersName: cn=Manager,c=AU
modifyTimestamp: 20080906145740Z
structuralObjectClass: subentry
subschemaSubentry: cn=Subschema

(Incidentally very impressed that Apache Directory Studio can handle the above subschema stuff quite competently)

So although the configuration information is now present, i assume there is nothing actually using or applying this data. If i understand the above correctly, the intent is to apply the above values in c-PostalAddress and c-PostalCode, to the matching attributes postalAddress and postalCode for all entries under base "ou=test1,o=openldap,c=AU", with no exclusions

I'm thinking that it is a requirement to efficiently keep a list of objects matching (objectClass=collectiveAttributeSubentry) and then applying the specifications therein to search results. The existing collect overlay is a simple demonstration overlay, which keeps only a simple static definition which never changes, so does not implement collective attributes in the more complex dynamic form.

To implement collective attributes fully (and as declared in collective.schema) this meta data would need to be dynamic, but without the overhead of continually searching for new things matching (objectClass=collectiveAttributeSubentry) which would trash performance.

Any thoughts on how to go about implementing this ?

Cheers
Brett