On Fri, Sep 11, 2009 at 6:13 PM, Emmanuel Lecharny <email@example.com>
I have added the ou=schemaModifications ldif file in ldap-schema resources, but it's not enough. The RegistrySynchronizerAdaptor class needs to be fixed in order to update this entry when a schema element is modified.
Alex Karasulu wrote:
On Fri, Sep 11, 2009 at 4:08 PM, Emmanuel Lecharny <firstname.lastname@example.org>wrote:
cn=schemaModifications is used to track timestamps on the schema I think.
core-integ tests are being fixed slowly but surely. As of today, 164 tests
are failing, out of 399.
I still have some issues on modifications as we are trying to update some
data into a cn=schemaModifications,ou=schema entry. This entry does not
exist, and I don't know what it is supposed to contain. This impact a lot of
tests as many of them are enabling a schema, which means a modification in
the associated entry.
I'll have to look at it again though. Leave this to me this weekend, I
think I can scrub it clean.
Make me think that when we have updated the schema on disk, a second modification is done to update the modifyTimestamp and modifiersName operational attributes. In other words, we write the entry twice on disk. A waste, IMHO.
Yes we need to fix this. However this problem is not only a schema issue. It happens every time we change an entry period. This is definitely something to consider for optimization.
We should inject those Operational attribute in the list of modifications and apply them directly. That will have a direct impact on the OperationalAttribute interceptor.
Yes I agree however at the time we had some issue that prevented us from doing this. However this may have changed. We need to revisit all the write operations and optimize them.