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<[email protected]>
An: [email protected]
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-----

Reply via email to