Vidar Ramdal wrote: > On Thu, Feb 11, 2010 at 9:49 PM, Julian Sedding <jsedd...@day.com> wrote: >> As Carsten mentioned, it starts getting tricky when the >> write-capabilities of the Sling API are mixed with those of JCR. AFAIU >> the JcrModifiablePropertyMap is for convenience and thus optimized and >> limited for the use-case of setting properties on a single node. >> >> Would your problem be solved by a static helper method, accepting a >> Node and a Map/ValueMap to achieve the same thing, similar convenience >> and purely on the JCR API? I suppose this could go into the >> JcrResourceUtil. I.e. something like >> JcrResourceUtil.setProperties(Node, Map<String, Object>), which does >> not execute session.save(). > > That wouldn't help in my case, I think. The problem is not that > JcrModifiablePropertyMap calls session.save() (it doesn't), but it > calls node.save() which makes a session.refresh() useless. Node.save() and node.refresh() are deprecated with jcr 2.0 :)
> I admit the problem *is* a bit far-fetched, but I'd like to have a > completely resource-agnostic method of updating properties. So that > any resource that adapts to ModifiablePropertyMap can be updated. Yepp, I completly agree. Now, as a node.save() and node.refresh() are deprecated, I think the way the JcrModifiablePropertyMap currently works is very good, because you can revert changes on the resource - regardless how the repository works underneath. One day our resource resolver might support crud operations completly, but we're not there yet - maybe, we could add a save() method to the resource resolver and this saves all changes - including the ones in the JcrModifiablePropertyMaps (and any other resource providers). Not sure, if this is a good idea :) Carsten -- Carsten Ziegeler cziege...@apache.org
