Directory ApacheDS
  1. Directory ApacheDS
  2. DIRSERVER-888

Add a verification before deleting an Object Class in the schema

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5.0
    • Fix Version/s: 2.1.0
    • Component/s: None
    • Labels:
      None

      Description

      While I was playing a little with the new dynamic schema in ADS 1.5, I found an interesting situation.

      Here's the scenario:
      I created a new AT called 'MyAT' and a new OC called 'MyOC' which has 'MyAT' in its May list.

      After a refresh of the Connection in LDAP Studio, I was able to create a new entry using 'MyOC' as OC. This entry was 'MyAT=test, dc=example, dc=com'.

      Then I was wondering how would react the server if I delete 'MyAT' from the schema.
      I got a warning telling me that an entity was depending on it (it was 'MyOC' of course).
      Very Great!

      Then I tried to delete 'MyOC'... and then... no warning...
      I could delete it successfully.

      After that, I was also able to delete 'MyAT', since there was no more dependency on it.

      That left my server with a pretty strange situation : having an entry depending on OC and AT that doesn't exists anymore in the schema...

      While trying to load children of 'dc=example, dc=com', I got an error : "Error while reading entry
      [LDAP: error code 33 - failed on search operation: OID for name 'myoc' was not found within the OID registry]"

      I think it would be a good idea, before deleting an OC in the schema, to verify if there's not one (or more) entry depending on that OC.

        Activity

        Hide
        Emmanuel Lecharny added a comment -

        This is a complex issue. Let's add this feature in 1.5.3

        Show
        Emmanuel Lecharny added a comment - This is a complex issue. Let's add this feature in 1.5.3
        Hide
        Alex Karasulu added a comment -

        I was just thinking about this as well as other schema issues on a drive home. I think we can implement this using a counter on the metaXXXX objects. Basically we keep a special counter on attributeTypes and objectClasses called m-dependentEntries.

        When you add a new entry you increment the m-dependentEntries value of each schema entity that entry depends on. When you delete an entry you decrement the counter on each dependent schema entity. When you do modify operations it's slightly more complex since this means a potential mixture of increments and decrements. Like if you do a modify that deletes a may list attribute from an entry then you decrement the counter on that attributeType. If the modify also adds a new objectClass value and new attributes then you increment those schema entities etc.

        This way we know if entries in the server depend on schema elements without performing an expensive search to find all entries in massive directories.

        Thoughts?

        Show
        Alex Karasulu added a comment - I was just thinking about this as well as other schema issues on a drive home. I think we can implement this using a counter on the metaXXXX objects. Basically we keep a special counter on attributeTypes and objectClasses called m-dependentEntries. When you add a new entry you increment the m-dependentEntries value of each schema entity that entry depends on. When you delete an entry you decrement the counter on each dependent schema entity. When you do modify operations it's slightly more complex since this means a potential mixture of increments and decrements. Like if you do a modify that deletes a may list attribute from an entry then you decrement the counter on that attributeType. If the modify also adds a new objectClass value and new attributes then you increment those schema entities etc. This way we know if entries in the server depend on schema elements without performing an expensive search to find all entries in massive directories. Thoughts?
        Hide
        Alex Karasulu added a comment -

        Lots of schema work will go into 1.5.8 according to the revised roadmap. Delaying till then.

        Show
        Alex Karasulu added a comment - Lots of schema work will go into 1.5.8 according to the revised roadmap. Delaying till then.
        Hide
        Emmanuel Lecharny added a comment -

        Moved to 2.0.0-RC1, we won't release a 1.5.8

        Show
        Emmanuel Lecharny added a comment - Moved to 2.0.0-RC1, we won't release a 1.5.8
        Hide
        Kiran Ayyagari added a comment -

        I think the proposed solution to maintain a counter m-dependentEntries make add/delete operations
        to take more time. Personally I prefer to go with the 'search for any dependent entry(ies)
        containing the OC' approach, assuming that schema object(especially OC) deletion is a very very
        rare operation.

        Show
        Kiran Ayyagari added a comment - I think the proposed solution to maintain a counter m-dependentEntries make add/delete operations to take more time. Personally I prefer to go with the 'search for any dependent entry(ies) containing the OC' approach, assuming that schema object(especially OC) deletion is a very very rare operation.
        Hide
        Emmanuel Lecharny added a comment -

        Thinking about this, I see no reason why we should integrate it into 2.0-RC1.

        As the OC index references all the entries using a specific OC, it should be easy to know if it's used at all or not, no need to use extra storage for that.

        Now, as it's up to the admin to manage its database, I would rather not pollute the server with such checks in 2.0.

        Show
        Emmanuel Lecharny added a comment - Thinking about this, I see no reason why we should integrate it into 2.0-RC1. As the OC index references all the entries using a specific OC, it should be easy to know if it's used at all or not, no need to use extra storage for that. Now, as it's up to the admin to manage its database, I would rather not pollute the server with such checks in 2.0.

          People

          • Assignee:
            Alex Karasulu
            Reporter:
            Pierre-Arnaud Marcelot
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development