Details

    • Type: New Feature New Feature
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 0.7.0
    • Fix Version/s: None
    • Component/s: studio-ldapbrowser
    • Labels:
      None
    • Environment:
      FC6

      Description

      Actually this is probably more of a new feature than a bug...

      I created a
      schema entry
      like this:

      ou=attributeTypes,cn=ecore, ou=schema
      ou=syntaxes, cn=ecore, ou=schema

      I have one attributeType entry
      that depends on a syntax entry,
      under
      ou=syntaxes, cn=ecore, ou=schema

      When I select the entry
      cn=ecore, ou=schema
      and do a delete I get this:

      Error while deleting entry
      [LDAP: error code 53 - failed to delete entry m-oid=1.3.6.1.4.1.18060.4.98100505.1019857.4101539.5010251.6529753.1101991.0529799.955495751,ou=syntaxes,cn=ecore,ou=schema: The syntax with OID 1.3.6.1.4.1.18060.4.98100505.1019857.4101539.5010251.6529753.1101991.0529799.955495751 cannot be deleted until all entities using this syntax have also been deleted. The following dependees exist: [1.3.6.1.4.1.18060.4.98515110.5310256.9575156.5495150.9981025.4855551.2981009.98495457.4101]]
      [LDAP: error code 53 - failed to delete entry m-oid=1.3.6.1.4.1.18060.4.98100505.1019857.4101539.5010251.6529753.1101991.0529799.955495751,ou=syntaxes,cn=ecore,ou=schema: The syntax with OID 1.3.6.1.4.1.18060.4.98100505.1019857.4101539.5010251.6529753.1101991.0529799.955495751 cannot be deleted until all entities using this syntax have also been deleted. The following dependees exist: [1.3.6.1.4.1.18060.4.98515110.5310256.9575156.5495150.9981025.4855551.2981009.98495457.4101]]

      If I delete the entries in this sequence manually everything is fine:
      ou=attributeTypes,cn=ecore, ou=schema
      ou=syntaxes, cn=ecore, ou=schema
      cn=ecore, ou=schema

      So if the delete function has the intelligence
      to understand that it has to delete the syntaxes
      before it can delete attributeTypes, that would be cool.

      Cheers,

      • Ole

        Issue Links

          Activity

          Hide
          Ole Ersoy added a comment -

          I better stuff this in here too:

          After I delete the entry
          cn=ecore, ou=schema,
          I get the exception,
          but LS still removes the
          entry from the tree.

          Then when I refresh, it pops
          back in.

          Cheers,

          • Ole
          Show
          Ole Ersoy added a comment - I better stuff this in here too: After I delete the entry cn=ecore, ou=schema, I get the exception, but LS still removes the entry from the tree. Then when I refresh, it pops back in. Cheers, Ole
          Hide
          Emmanuel Lecharny added a comment -

          Oopps, bad move !

          I thought it was a bug, but it's a feature. Reopened

          Show
          Emmanuel Lecharny added a comment - Oopps, bad move ! I thought it was a bug, but it's a feature. Reopened
          Hide
          Emmanuel Lecharny added a comment -

          As explain by Alex, this is the intended behavior

          Show
          Emmanuel Lecharny added a comment - As explain by Alex, this is the intended behavior
          Hide
          Ole Ersoy added a comment -

          Stefan Seelmann wrote:
          > Ole,
          >
          > I don't think it makes sense to add such semantics into the default
          > delete operation of the browser.

          Sure. The use case for me anyways is just to
          be able to quickly delete some schema containers
          while debugging junit tests...and I understand
          that there are probably cross LDAP server considerations, etc...
          which makes bloating the delete function less sexy...

          > What we could do is the following: PAM and I would like to extend the
          > current Schemas Editor to operate directly on the schema partition of
          > ADS instead of .schema files. So we have to add this functionality into
          > the Schemas Editor:
          >
          > - When saving a new schema into the schema partition we have to consider
          > the correct order (syntaxes before matching rules before attribute types
          > before object classes)
          >
          > - When deleting a schema we have to consider the inverse order
          >
          > Sounds good?

          Smoookkin!! U and PAM Da Mans!

          Should I just close this then like Alex recommended?

          Oh - Incidentally this thought just popped in.
          Suppose I was editing the Schema partition
          entries through the browser, like I was doing.

          Once the Schemas editor connects directly to ADS,
          might it make sense to "Switch" the delete action
          to the one used by the Schemas Editor, when
          connecting to the schema through the browser?

          Thus the delete action implementation
          being used would depend on whether the partition being
          connected to is ADS's schema partition.

          I need to review the IAdaptable pattern the Eclipse APIs
          use, but I think that if the action were an IAdaptable
          then selecting the implementation for the delete action
          could made fairly elegant.

          So if ou=schema is the partition, then the cascading delete
          stuff becomes possible by delegating the delete action request
          to the CasacdingDelete action, but for all other partitions
          and connections it's the other delete action implementation.

          This might provide for a better ADS dynamic schema editing
          experience.

          Now it's sort of like this same feature request again

          Anyways it might be a feature suggestion that could
          just hang around on in the periphery of LS feature requests,
          and then if for some reason others start requesting a pluggable/switchable
          action API in LS, then then maybe it gets interesting.

          Or we could just nuke it I have both keys. Just give me the signal

          Cheers,

          • Ole

          SNIP

          Show
          Ole Ersoy added a comment - Stefan Seelmann wrote: > Ole, > > I don't think it makes sense to add such semantics into the default > delete operation of the browser. Sure. The use case for me anyways is just to be able to quickly delete some schema containers while debugging junit tests...and I understand that there are probably cross LDAP server considerations, etc... which makes bloating the delete function less sexy... > What we could do is the following: PAM and I would like to extend the > current Schemas Editor to operate directly on the schema partition of > ADS instead of .schema files. So we have to add this functionality into > the Schemas Editor: > > - When saving a new schema into the schema partition we have to consider > the correct order (syntaxes before matching rules before attribute types > before object classes) > > - When deleting a schema we have to consider the inverse order > > Sounds good? Smoookkin!! U and PAM Da Mans! Should I just close this then like Alex recommended? Oh - Incidentally this thought just popped in. Suppose I was editing the Schema partition entries through the browser, like I was doing. Once the Schemas editor connects directly to ADS, might it make sense to "Switch" the delete action to the one used by the Schemas Editor, when connecting to the schema through the browser? Thus the delete action implementation being used would depend on whether the partition being connected to is ADS's schema partition. I need to review the IAdaptable pattern the Eclipse APIs use, but I think that if the action were an IAdaptable then selecting the implementation for the delete action could made fairly elegant. So if ou=schema is the partition, then the cascading delete stuff becomes possible by delegating the delete action request to the CasacdingDelete action, but for all other partitions and connections it's the other delete action implementation. This might provide for a better ADS dynamic schema editing experience. Now it's sort of like this same feature request again Anyways it might be a feature suggestion that could just hang around on in the periphery of LS feature requests, and then if for some reason others start requesting a pluggable/switchable action API in LS, then then maybe it gets interesting. Or we could just nuke it I have both keys. Just give me the signal Cheers, Ole SNIP
          Hide
          Stefan Seelmann added a comment -

          I don't think it makes sense to add such semantics into the default
          delete operation of the browser.

          What we could do is the following: PAM and I would like to extend the
          current Schemas Editor to operate directly on the schema partition of
          ADS instead of .schema files. So we have to add this functionality into
          the Schemas Editor:

          • When saving a new schema into the schema partition we have to consider
            the correct order (syntaxes before matching rules before attribute types
            before object classes)
          • When deleting a schema we have to consider the inverse order

          So I would recommend to close this issue and to create a new feature request for the schemas editor.

          Show
          Stefan Seelmann added a comment - I don't think it makes sense to add such semantics into the default delete operation of the browser. What we could do is the following: PAM and I would like to extend the current Schemas Editor to operate directly on the schema partition of ADS instead of .schema files. So we have to add this functionality into the Schemas Editor: When saving a new schema into the schema partition we have to consider the correct order (syntaxes before matching rules before attribute types before object classes) When deleting a schema we have to consider the inverse order So I would recommend to close this issue and to create a new feature request for the schemas editor.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ole Ersoy
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development