software engineering question

[ChadDavis <ch...@gmail.com>]

I'm curious as to the design motivations behind some of the Jackrabbit
code.  I'm not questioning these choices.  I'm actually trying to
learn from them.  In particular, I'm interested in the motivations
that lead to the deprecation of node.save() in favor of
session.save().  Any insight would be appreciated.  Thanks!

RE: software engineering question

[Jukka Zitting <jz...@adobe.com>]

Hi,

From: ChadDavis [mailto:chadmichaeldavis@gmail.com]
> I'm curious as to the design motivations behind some of the Jackrabbit
> code.  I'm not questioning these choices.  I'm actually trying to
> learn from them.  In particular, I'm interested in the motivations
> that lead to the deprecation of node.save() in favor of
> session.save().  Any insight would be appreciated.  Thanks!

There are some repository implementations that have trouble selectively saving parts of the transient space, and the use case for doing that was not considered too important by the JSR 283 expert group.

Jackrabbit implements both Item.save() and Session.save().

BR,

Jukka Zitting

AW: software engineering question

[Clemens Wyss <cl...@mysign.ch>]

I can imagine that when you modify 1'000s of nodes (say in a batch) you win quite some time when you don't save each node "per se" but in the end just tell the session to persist all its pending changes. Just a guess though...

-----Ursprüngliche Nachricht-----
Von: justinedelson@gmail.com [mailto:justinedelson@gmail.com] Im Auftrag von Justin Edelson
Gesendet: Dienstag, 16. November 2010 19:32
An: users@jackrabbit.apache.org
Betreff: Re: software engineering question

FWIW, this is actually a spec question, not a Jackrabbit question.

Justin

On Tue, Nov 16, 2010 at 1:11 PM, ChadDavis <ch...@gmail.com> wrote:
> I'm curious as to the design motivations behind some of the Jackrabbit 
> code.  I'm not questioning these choices.  I'm actually trying to 
> learn from them.  In particular, I'm interested in the motivations 
> that lead to the deprecation of node.save() in favor of 
> session.save().  Any insight would be appreciated.  Thanks!
>

Re: software engineering question

[Justin Edelson <ju...@justinedelson.com>]

FWIW, this is actually a spec question, not a Jackrabbit question.

Justin

On Tue, Nov 16, 2010 at 1:11 PM, ChadDavis <ch...@gmail.com> wrote:
> I'm curious as to the design motivations behind some of the Jackrabbit
> code.  I'm not questioning these choices.  I'm actually trying to
> learn from them.  In particular, I'm interested in the motivations
> that lead to the deprecation of node.save() in favor of
> session.save().  Any insight would be appreciated.  Thanks!
>

Re: software engineering question

[Alexander Klimetschek <ak...@adobe.com>]

BTW, node.save() still works in Jackrabbit 2.x.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: software engineering question

[Alexander Klimetschek <ak...@adobe.com>]

On 16.11.10 19:11, "ChadDavis" <ch...@gmail.com> wrote:

>I'm curious as to the design motivations behind some of the Jackrabbit
>code.  I'm not questioning these choices.  I'm actually trying to
>learn from them.  In particular, I'm interested in the motivations
>that lead to the deprecation of node.save() in favor of
>session.save().  Any insight would be appreciated.  Thanks!
>

This was changed in the spec for the benefit of implementors. Supporting
node.save() is/can be much more difficult (especially when writing a JCR
connector to an existing repository system). Having a single session
save() is what all databases do, because it can be implemented simpler,
more scalable, etc.

For applications node.save() often seems much more convenient, but if you
think through it, it often is better to resort to a session.save() that
includes the entire transaction. If only storing a subtree before other
things that have already been changed is really needed, one can have a
second session for that part.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel