From users-return-17647-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Thu Jun 16 08:39:26 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 0B280646F
for ; Thu, 16 Jun 2011 08:39:26 +0000 (UTC)
Received: (qmail 48554 invoked by uid 500); 16 Jun 2011 08:39:25 -0000
Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org
Received: (qmail 48525 invoked by uid 500); 16 Jun 2011 08:39:25 -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 48517 invoked by uid 99); 16 Jun 2011 08:39:25 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jun 2011 08:39:25 +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 (athena.apache.org: domain of anchela@adobe.com designates 64.18.1.208 as permitted sender)
Received: from [64.18.1.208] (HELO exprod6og107.obsmtp.com) (64.18.1.208)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jun 2011 08:39:17 +0000
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP
ID DSNKTfnBHxzfo2t5pAYl5bgXASfx34Dw8WGS@postini.com; Thu, 16 Jun 2011 01:38:56 PDT
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51])
by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p5G8crSC017449
for ; Thu, 16 Jun 2011 01:38:54 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121])
by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p5G8crPY020210
for ; Thu, 16 Jun 2011 01:38:53 -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:38:53 -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:38:52 +0100
Message-ID: <4DF9C11C.7070206@adobe.com>
Date: Thu, 16 Jun 2011 10:38:52 +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> <20110614085527.287810@gmx.net>
In-Reply-To: <20110614085527.287810@gmx.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
hi johannes
from the webdav server side it should be possible to create
referenceable node and a property referring to it in a single
save call.
but you have to know the jcr:uuid in order to set it in the
referenceable property. however, the format of that uuid is
implementation specific. in other words: you would make sure
you create the nodes and the ref-properties with a value
valid for the backend.
so, i guess at the moment it would be the responsibility of your
PHP JCR API implementation to generated a valid uuid since
there is no way to call "generateUUID" neither on SPI nor on the
DAV-server implementation.
regards
angela
On 6/14/11 10:55 AM, Johannes Stark wrote:
> 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 poperties 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
>