Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 50300 invoked from network); 26 Sep 2009 07:22:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Sep 2009 07:22:41 -0000 Received: (qmail 85185 invoked by uid 500); 26 Sep 2009 07:22:41 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 84854 invoked by uid 500); 26 Sep 2009 07:22:40 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 84832 invoked by uid 99); 26 Sep 2009 07:22:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Sep 2009 07:22:40 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Sep 2009 07:22:37 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 9B3F4234C004 for ; Sat, 26 Sep 2009 00:22:16 -0700 (PDT) Message-ID: <1230854865.1253949736621.JavaMail.jira@brutus> Date: Sat, 26 Sep 2009 00:22:16 -0700 (PDT) From: "Emmanuel Lecharny (JIRA)" To: dev@directory.apache.org Subject: [jira] Created: (DIRSERVER-1412) Modifying the schema with more than one mod may fail MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org Modifying the schema with more than one mod may fail ---------------------------------------------------- Key: DIRSERVER-1412 URL: https://issues.apache.org/jira/browse/DIRSERVER-1412 Project: Directory ApacheDS Issue Type: Bug Affects Versions: 1.5.5 Reporter: Emmanuel Lecharny Priority: Minor Fix For: 2.5.0 When applying some schema modification as one single modify() operation, if there are more than one schema modifications, we may have failures : - first we can't guarantee the atomicity as all the parsing are done first, and as the integrity check are done during parsing, we have corner case which will throw an exception. For instance, if we have 2 AT being injected, one being the other's superior, as the superior has not been injected into the schema, the second AT may complain about the missing superior AT - second if for some reason we have a failure in the middle of the processing, we won't be able to revert all the previous additions. Both issues can be fixed, but I'm not sure it worth the pain of having a shadow registry in which we apply the changes until we are sure we are fine with all the modifications, before updating the real schema. IMO, that would be better to forbid schema modifications with more than one modification in the modify parameters. A slight violation of the protocol, but really not that important. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.