You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2015/02/14 04:21:34 UTC

JcrModifiableValueMap does not support session.refresh(false)

Because of the readFully() feature, that at some time always gets called, the JcrModifiableValueMap will cache all the node's properties once read. Thus if you later do a session.refresh(false) in JCR, which discards transient changes, the value map will not know about it and keep returning cached transient changes.

We have a use case where we want this behavior and have a complete custom copy of the JcrModifiableValueMap code with the few changes. Obviously the code duplication is bad.

Can we improve on that? Make this optional?

It also has the need to write changes directly, this was once requested in SLING-1391 [1] which is marked as wontfix, however, it looks to me like the JcrModifiableValueMap nowadays writes immediately to the JCR [2].

[1] https://issues.apache.org/jira/browse/SLING-1391
[2] https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/JcrModifiableValueMap.java#L451-L462

Cheers,
Alex

Re: JcrModifiableValueMap does not support session.refresh(false)

Posted by Carsten Ziegeler <cz...@apache.org>.
Am 14.02.15 um 21:24 schrieb Alexander Klimetschek:
> On 14.02.2015, at 01:39, Carsten Ziegeler <cz...@apache.org> wrote:
>> A value map can be seen as a copy of the data at the point it was
>> created. And especially as you know that you're doing a refresh,
>> why can't you refetch the value map once you did the refresh?
>>
>> Transparently handling a session refresh is not that easy, it might work
>> for your case and the value map. But I guess there are a lot of cases
>> where this doesn't work - or even is unexpected. Therefore simply
>> getting resources and representations again after a refresh is the
>> simplest and cleanest solution
> 
> I agree, but the code I was looking at seems to have its API designed based on that, hence it has its own modifying value map implementation... and I'd like to get rid of it. One could have an option in the JcrModifiableValueMap constructor for this - and by default it would not be used.
>
Let's assume we have the option in the constructor, how do you select
which arg is passed to it?

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: JcrModifiableValueMap does not support session.refresh(false)

Posted by Alexander Klimetschek <ak...@adobe.com>.
On 14.02.2015, at 01:39, Carsten Ziegeler <cz...@apache.org> wrote:
> A value map can be seen as a copy of the data at the point it was
> created. And especially as you know that you're doing a refresh,
> why can't you refetch the value map once you did the refresh?
> 
> Transparently handling a session refresh is not that easy, it might work
> for your case and the value map. But I guess there are a lot of cases
> where this doesn't work - or even is unexpected. Therefore simply
> getting resources and representations again after a refresh is the
> simplest and cleanest solution

I agree, but the code I was looking at seems to have its API designed based on that, hence it has its own modifying value map implementation... and I'd like to get rid of it. One could have an option in the JcrModifiableValueMap constructor for this - and by default it would not be used.

The other approach of connecting a resource resolver refresh() with all value maps is probably not trivial and creates complex link between all the objects...

Cheers,
Alex

Re: JcrModifiableValueMap does not support session.refresh(false)

Posted by Carsten Ziegeler <cz...@apache.org>.
Am 14.02.15 um 04:21 schrieb Alexander Klimetschek:
> Because of the readFully() feature, that at some time always gets called, the JcrModifiableValueMap will cache all the node's properties once read. Thus if you later do a session.refresh(false) in JCR, which discards transient changes, the value map will not know about it and keep returning cached transient changes.
> 
> We have a use case where we want this behavior and have a complete custom copy of the JcrModifiableValueMap code with the few changes. Obviously the code duplication is bad.
> 
> Can we improve on that? Make this optional?
> 
A value map can be seen as a copy of the data at the point it was
created. And especially as you know that you're doing a refresh,
why can't you refetch the value map once you did the refresh?

Transparently handling a session refresh is not that easy, it might work
for your case and the value map. But I guess there are a lot of cases
where this doesn't work - or even is unexpected. Therefore simply
getting resources and representations again after a refresh is the
simplest and cleanest solution

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org