Hi, Am 30.07.2012 um 12:53 schrieb Carsten Ziegeler:
> 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. The question probably is, whether we expect the operation to generally succeed or not. My impression is, that on put, we expect the operation to generally succeed and on commit to be prepared for the operation to fail. > 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 > :( Ok. For an FS provider the files and folders could be created in a temporary space and moved into the final location on commit. > >> >> I will have some more general comments on the current trunk in a separate >> thread. >> > Great! > > Carsten > > > > -- > Carsten Ziegeler > [email protected]
