2012/7/30 Felix Meschberger <[email protected]>:

>
> As indicated above, my preference would be a "modified version of half-way 
> proposal 2":
>
>   * Map.put/putAll is reused pushing into the ResourceProvider's
>     transient space directly (for JCR this directly uses Node.setProperty)
>   * Any persistence exceptions are wrapped into one of the defined
>     runtime exceptions (e.g. ValueFormatException wrapped into 
> ClassCastException)
>   * Set views are unmodifiable
>   * To actually persist any changes the ResourceResolver.commit method is used
>
> WDYT ?

To be honest, this looks like the logical solution, however I really
feel uneasy with throwing a runtime exception on a put call. While
this is allowed, it is very unexpected from a user pov.
But we could try going this way.

>
> Follow-up questions: Do all ModifyingResourceProvider implementations have to 
> provide a transient space ? I am thinking of a Filesystem based 
> implementation.
So far, yes all providers are assumed to have a transient space. Not
sure if this is a good idea, I'm currently writing a MongoDB provider
and in this case handling the transient space is not that difficult.
I think this goes hand and hand with the model of transactions
especially rollback we come up with. Right now there is now rollback
:(

>
> I will have some more general comments on the current trunk in a separate 
> thread.
>
Great!

Carsten



-- 
Carsten Ziegeler
[email protected]

Reply via email to