From dev-return-16558-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Fri Feb 01 08:05:32 2008 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 4897 invoked from network); 1 Feb 2008 08:05:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Feb 2008 08:05:32 -0000 Received: (qmail 53702 invoked by uid 500); 1 Feb 2008 08:05:23 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 53342 invoked by uid 500); 1 Feb 2008 08:05:22 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 53322 invoked by uid 99); 1 Feb 2008 08:05:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2008 00:05:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of anchela@day.com designates 62.192.10.254 as permitted sender) Received: from [62.192.10.254] (HELO goobak01.day.com) (62.192.10.254) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Feb 2008 08:05:07 +0000 Received: by goobak01.day.com (Postfix, from userid 1212) id 18B7F50874; Fri, 1 Feb 2008 08:55:39 +0100 (CET) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by goobak01.day.com (Postfix) with ESMTP id 05C655086F for ; Fri, 1 Feb 2008 08:55:36 +0100 (CET) Received: by rv-out-0910.google.com with SMTP id k20so750900rvb.1 for ; Fri, 01 Feb 2008 00:04:55 -0800 (PST) Received: by 10.141.37.8 with SMTP id p8mr2274182rvj.150.1201853095390; Fri, 01 Feb 2008 00:04:55 -0800 (PST) Received: from ?10.0.0.71? ( [62.192.10.254]) by mx.google.com with ESMTPS id 39sm6565390wrl.2.2008.02.01.00.04.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Feb 2008 00:04:54 -0800 (PST) Message-ID: <47A2D2FE.2020709@day.com> Date: Fri, 01 Feb 2008 09:06:22 +0100 From: Angela Schreiber User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: SPI: setValue vs addProperty References: <47A1E1C1.2050107@gmx.de> In-Reply-To: <47A1E1C1.2050107@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Julian Reschke wrote: > Hi, > > currently SPI Batch distinguishes between adding a property, and setting > the value of a property. In JCR however, this distinction does not exist. > This test will only pass if SPI's Batch.addProperty actually behaves the > same way as setValue, meaning overwriting an existing property. > > Questions: > > 1) Should we update the Javadoc to clarify that this is what it is > expected? yes. > 2) Should we remove one of the signatures, because the distinction > wasn't useful after all? rather not. you shouldn't be able to modify the value of a property that doesn't exist any more... that might happen if the client is not up-to-date. however the spi-correspondence of Node.setProperty (means: add the property if missing or change its value if it exists) should work then. angela