...
This is a concept how to fully implement CRUD via the resource API. As a first step we angle the problem from the users via: the API to be used by Sling applications. (SLING-2530)
Client API
Read
The support for read is sufficient, we don't need to change that much.
...
We add a delete method to the Resource interface, so deleting a resource is a two way step: first getting the resource from the resource resolver and then deleting it. The change is persisted immediately (see below)
There is no benefit in having a delete(String path) method on the resource resolver. This would internally get the resource first anyway in order to delegate to the proper resource provider.
See section about persisting changes belowe.
Create
We add a new method create(String absolutePath, ValueMap properties) to the resource resolver, where the value map is optional. This will create the resource at the given path and add the provided properties. The change is persisted immediately (see below)
In the case of a JCR backed repository, the properties might contain jcr:primaryType and jcr:mixins - which are used to set the node node and mixins. Otherwise the defaults apply.
See section about persisting changes belowe.
Update
We currently have the PersistableValueMap which is an easy way of modifying a resource. As we have modifications now as a first class feature, we should add an update(ValueMap props) method to the Resource interface. The change is persisted immediately
See section about persisting changes belowe.
We should deprecate the PersistableValueMap as a save() call saves the whole session and this might include changes made through any other means to the session.(see SLING-1391 for some discussion about this)
Persisting Changes
...
There are two possibilities to handle changes:
- A call to one of the methods, modifying a resource as outlined above are persisted immediately
...
- and JTA transactions will be supported
...
- Changes are not persisted immediately but stored transient. When all changes are done, a save/commit calls needs to be done trying to persist all changes to all resource providers.
The second approach is more like people are used to when they are familiar with JCR and it allows to do bulk changes to the persistence. The first approach without using a transaction is easier to implement inside the resource providers and for many use cases sufficient as usually just a single resource is affected by REST calls
Transaction handling
As changes are persisted immediately, there might be some need for a transaction handling to control resource operations in a better way. Therefore the underlying resource providers should support JTA.
Resource Providers
A resource provider is mounted into the resource tree. In general, the providers are processed ordered by service ranking, highest first. A service provider gets a service property specifying the sub tree it is claiming to use. For example, a service provider might be mounted at /a/some/path. Everything below this path is processed by this resource resolver. However another resource provider might claim /a/some/path/and/down. So the longest matching path wins.
...