From users-return-17646-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Jun 16 08:31:59 2011 Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4167E66FF for ; Thu, 16 Jun 2011 08:31:59 +0000 (UTC) Received: (qmail 42121 invoked by uid 500); 16 Jun 2011 08:31:58 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 42098 invoked by uid 500); 16 Jun 2011 08:31:58 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 42090 invoked by uid 99); 16 Jun 2011 08:31:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jun 2011 08:31:58 +0000 X-ASF-Spam-Status: No, hits=-1.2 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates 64.18.1.187 as permitted sender) Received: from [64.18.1.187] (HELO exprod6og104.obsmtp.com) (64.18.1.187) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jun 2011 08:31:51 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKTfm/YBn7PVIM2ooyG9+XbAH7AQb2jWjt@postini.com; Thu, 16 Jun 2011 01:31:30 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p5G8VQSC016960 for ; Thu, 16 Jun 2011 01:31:27 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p5G8VKaQ021159 for ; Thu, 16 Jun 2011 01:31:25 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.159.3; Thu, 16 Jun 2011 01:31:20 -0700 Received: from Angela.local (10.132.1.193) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.159.3; Thu, 16 Jun 2011 09:31:17 +0100 Message-ID: <4DF9BF55.2060407@adobe.com> Date: Thu, 16 Jun 2011 10:31:17 +0200 From: Angela Schreiber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "users@jackrabbit.apache.org" Subject: Re: Adding nodes with references within a single transaction via webdav References: <20110609134541.4730@gmx.net> <4DF1D573.5050008@adobe.com> <20110614083451.115910@gmx.net> <4DF9B4B6.6070803@liip.ch> In-Reply-To: <4DF9B4B6.6070803@liip.ch> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org hi david > @angela: how does jackrabbit-core make the node referenceable > immediatly? jackrabbit-core uses the node's ID, which is generated upon creation as jcr:uuid as soon as the node is referenceable either by nt inheritance or by adding the mixin. > does it create a temporary uuid? no. > or is there a way to set > the uuid through spi, the Batch#addNode method has a uuid parameter. this is e.g. used to transport Session#importXML > so that we could generate the uuid in the client? the problem with the uuid generated on the client is that the client basically doesn't know what kind of uuid-format is suitable for the server... that's why in jcr2spi a fake value is generated for the jcr:uuid property. > (when importing a system view dump, this seems to be possible...) yes... there the jcr:uuid property can be passed in. the JCR API however does not allow to specify the id of a node that is being created. regards angela > cheers, > david > > > Am 14.06.2011 10:34, schrieb Johannes Stark: >> Hi Angela, >> >> we are using the Jackrabbit Standalone Server and access it via WebDav. So it's case b_. >> Well what we do is to rebuild the JCR API in PHP. We have a PHP session that simulates the JCR session. All changes made are cached by the PHP session. On $session->save() all changes are written to Jackrabbit via webdav. It's working great unless for references to new nodes within a session due to the unavailability of uuids. So our thought for the proceeding within PHP was the following: >> >> - start a PHP session >> - begin transaction >> - do some work in the PHP cache like adding nodes and properties (unless properties containing references) >> - save session (write everything to Jackrabbit, uuids of new referencable nodes should be available after that) >> - create all references in the PHP cache >> - save session again (write references to Jackrabbit) >> - commit transaction >> >> We would like to do it this way because that would give us the ability to do a rollback in case of an error during all the writing. >> >> So I would be great if uuids of new referenceable nodes would be available immediately after they were created via webdav within a transaction. >> >> >> Kind regards, >> Johannes >> >> >> -------- Original-Nachricht -------- >>> Datum: Fri, 10 Jun 2011 10:27:31 +0200 >>> Von: Angela Schreiber >>> An: users@jackrabbit.apache.org >>> Betreff: Re: Adding nodes with references within a single transaction via webdav >> >>> hi johannes >>> >>> the subject "Adding nodes with references within a single transaction >>> via webdav" somehow leaves me uncertain if i understand your issue. >>> >>> a_ are you taking about a jcr2spi repository? >>> b_ or are you talking about the webdav server implementation? >>> >>>> What we definitely need for our CMF are references between JCR nodes. >>> E.g. you would like to assign pages to menu items or you would like to have a >>> picture on several pages and so on. >>>> But one big problem for us is that you are not able to reference a node >>> until it is persisted. We also had a look at transactions: same issue. >>> Referenceable nodes will get their uuid not before the transaction is >>> committed. So we are not able to persist two or more content items with references >>> to each other within the same transaction. Well this behavior is totally in >>> accordance to the spec. >>> >>> in case of a_: >>> >>> that's correct. node are only referenceable once the jcr:uuid property >>> has been persisted. the reason for this is that the final nature of the >>> uuid is defined by the backend and there is little jcr2spi can do about >>> this (except if there was an explicit call to the spi-implementation to >>> generate the uuid which would as well generated some extra round trips). >>> >>> in case of b_: >>> i think that should be possible as the underlying jcr implementation is >>> a jackrabbit-core which makes a node referenceable immediately. >>> >>> kind regards >>> angela >> > > - -- > Liip AG // Agile Web Development // T +41 26 422 25 11 > CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk35tLYACgkQqBnXnqWBgIvMYACgtQbiMcfyFQAoZMGZxRaMfS/H > NUsAn1PK1R1r5P8Zmz0xx9MQKnQSQ7vi > =Were > -----END PGP SIGNATURE-----