directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ole Ersoy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSTUDIO-109) Schema Entry Deletes Must be Sequenced
Date Wed, 23 May 2007 21:56:16 GMT

    [ https://issues.apache.org/jira/browse/DIRSTUDIO-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498398
] 

Ole Ersoy commented on DIRSTUDIO-109:
-------------------------------------

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


> Schema Entry Deletes Must be Sequenced
> --------------------------------------
>
>                 Key: DIRSTUDIO-109
>                 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-109
>             Project: Directory LDAP Studio
>          Issue Type: New Feature
>          Components: ldapstudio-browser
>    Affects Versions: 0.7.0
>         Environment: FC6
>            Reporter: Ole Ersoy
>            Priority: Minor
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message