You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2012/07/18 09:30:49 UTC
[RT] API for modifying resources
Hi,
I'm currently working on CRUD support for Sling based on the resource
API. Current trunk contains already a version of it.
I'm wondering what the best api for modifying resources is.
Right now, the idea is to adapt a resource to ModifiableValueMap which
is an extension of the ValueMap. Like the PersistableValueMap this map
collects all changes internally. It provides an update() method which
pushes the changes into the transient persistence layer (e.g. jcr
session). A call to the resource resolver finally persists all
transient changes (let's forget about different resource providers and
transactions for now)
This approach has the advantage to reuse the map interface to change
values, no exceptions are thrown on put and remove. - but it requires
to additional calls, update on the map and commit on the resource
resolver to get the changes persisted.
I thought of changing this and push each change directly into the
transient store, so a call to put() or remove() on the map is directly
pushed through - this avoids the extra call to update(), however put()
and remove() have no checked exceptions declared. So we can either
throw undeclared exceptions (which I think is not really a good idea
in this case) or defer exception throwing until the commit call on the
resource resolver. But obviously this gets nasty if e.g. a put() is
not successful, doesn't throw an exception and one is doing a get on
the same property etc.
So, final solution would be to add special methods like set and delete
which might throw PersistenceException - and avoid reuse of modifying
methods from the map interface. Simpler to use compared to the current
version in trunk but additional methods.
Right now I'm undecided between the first and the last solution - with
a slight preference of the current version from trunk.
But maybe there are other/better options?
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 30.07.2012 um 14:18 schrieb Mike Müller:
>>> A little bit late...
>>> I find it quite natural to first set the changes with put and remove and
>>> after that call update to make the changes persistent. That's very similar
>>> to how OR mappers or also JCR with the session works.
>>> But if I get you right, after the call of update on the ModifiableValueMap
>>> the changes (for JCR) are only in the session and not saved. You also
>>> have to call commit on the ResourceProvider. That could be a good
>>> thing if we really want to support transactions in the future. But it means
>>> also that the ResourceProvider has to be known by the user which changes
>>> the resource.
>>
>> Actually the user calls the commit method on the ResourceResolver which forwards
>> that to the ResourceProviders internally. Clients/users never interact with
>> ResourceProviders directly -- they can't, since they don't know them.
>
> Ok, in this case we expect that there's only one ResourceResolver, otherwise
> we can't decide which ResourceResolver we should call. Is that correct, or is
> it possible that we have more than one ResourceResolver in the future?
Well, there is a ResourceResolverFactory service from which ResourceResolver instances can be retrieved. Technically there may be more than one ResourceResolverFactory services but practically, there won't.
Specifically during request processing there is the ResourceResolver available from SlingHttpServletRequest.getResourceResolver which is used during processing.
Regards
Felix
RE: [RT] API for modifying resources
Posted by Mike Müller <mi...@mysign.ch>.
> > A little bit late...
> > I find it quite natural to first set the changes with put and remove and
> > after that call update to make the changes persistent. That's very similar
> > to how OR mappers or also JCR with the session works.
> > But if I get you right, after the call of update on the ModifiableValueMap
> > the changes (for JCR) are only in the session and not saved. You also
> > have to call commit on the ResourceProvider. That could be a good
> > thing if we really want to support transactions in the future. But it means
> > also that the ResourceProvider has to be known by the user which changes
> > the resource.
>
> Actually the user calls the commit method on the ResourceResolver which forwards
> that to the ResourceProviders internally. Clients/users never interact with
> ResourceProviders directly -- they can't, since they don't know them.
Ok, in this case we expect that there's only one ResourceResolver, otherwise
we can't decide which ResourceResolver we should call. Is that correct, or is
it possible that we have more than one ResourceResolver in the future?
best regards
mike
Re: [RT] API for modifying resources
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 29.07.2012 um 15:06 schrieb Mike Müller:
> Hi
>
> A little bit late...
> I find it quite natural to first set the changes with put and remove and
> after that call update to make the changes persistent. That's very similar
> to how OR mappers or also JCR with the session works.
> But if I get you right, after the call of update on the ModifiableValueMap
> the changes (for JCR) are only in the session and not saved. You also
> have to call commit on the ResourceProvider. That could be a good
> thing if we really want to support transactions in the future. But it means
> also that the ResourceProvider has to be known by the user which changes
> the resource.
Actually the user calls the commit method on the ResourceResolver which forwards that to the ResourceProviders internally. Clients/users never interact with ResourceProviders directly -- they can't, since they don't know them.
> Further, if someone likes to create a new resource the
> right ResourceProvider also has to be known, to call create on it. Same
> case if you want to delete a resource, because the delete method is on
> the ResourceProvider. Wouldn't it be easier if the delete method is on
> the resource and the update method on the ModifiableValueMap makes
> the changes really persistent. If we decide to introduce transactions in
> the future we could extend these methods and hand over a context
> object for the transaction or something like that.
The ResourceResolver selects the appropriate ResourceProvider using resource path best match in the same way as done for the accessing (reading) the resources.
Hope this helps.
Regards
Felix
>
> Please pardon me if I got something incorrect, but isn't it the same case
> if I want to create a new resource: I have to know the right
> ResourceProvider to call create on it. Shouldn't Sling provide some
> help and call the right ResourceProvider for you?
>
> best regards
> mike
>
>
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: Wednesday, July 18, 2012 9:31 AM
>> To: dev@sling.apache.org
>> Subject: [RT] API for modifying resources
>>
>> Hi,
>>
>> I'm currently working on CRUD support for Sling based on the resource
>> API. Current trunk contains already a version of it.
>> I'm wondering what the best api for modifying resources is.
>>
>> Right now, the idea is to adapt a resource to ModifiableValueMap which
>> is an extension of the ValueMap. Like the PersistableValueMap this map
>> collects all changes internally. It provides an update() method which
>> pushes the changes into the transient persistence layer (e.g. jcr
>> session). A call to the resource resolver finally persists all
>> transient changes (let's forget about different resource providers and
>> transactions for now)
>> This approach has the advantage to reuse the map interface to change
>> values, no exceptions are thrown on put and remove. - but it requires
>> to additional calls, update on the map and commit on the resource
>> resolver to get the changes persisted.
>>
>> I thought of changing this and push each change directly into the
>> transient store, so a call to put() or remove() on the map is directly
>> pushed through - this avoids the extra call to update(), however put()
>> and remove() have no checked exceptions declared. So we can either
>> throw undeclared exceptions (which I think is not really a good idea
>> in this case) or defer exception throwing until the commit call on the
>> resource resolver. But obviously this gets nasty if e.g. a put() is
>> not successful, doesn't throw an exception and one is doing a get on
>> the same property etc.
>>
>> So, final solution would be to add special methods like set and delete
>> which might throw PersistenceException - and avoid reuse of modifying
>> methods from the map interface. Simpler to use compared to the current
>> version in trunk but additional methods.
>>
>> Right now I'm undecided between the first and the last solution - with
>> a slight preference of the current version from trunk.
>>
>> But maybe there are other/better options?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
RE: [RT] API for modifying resources
Posted by Mike Müller <mi...@mysign.ch>.
Hi
A little bit late...
I find it quite natural to first set the changes with put and remove and
after that call update to make the changes persistent. That's very similar
to how OR mappers or also JCR with the session works.
But if I get you right, after the call of update on the ModifiableValueMap
the changes (for JCR) are only in the session and not saved. You also
have to call commit on the ResourceProvider. That could be a good
thing if we really want to support transactions in the future. But it means
also that the ResourceProvider has to be known by the user which changes
the resource. Further, if someone likes to create a new resource the
right ResourceProvider also has to be known, to call create on it. Same
case if you want to delete a resource, because the delete method is on
the ResourceProvider. Wouldn't it be easier if the delete method is on
the resource and the update method on the ModifiableValueMap makes
the changes really persistent. If we decide to introduce transactions in
the future we could extend these methods and hand over a context
object for the transaction or something like that.
Please pardon me if I got something incorrect, but isn't it the same case
if I want to create a new resource: I have to know the right
ResourceProvider to call create on it. Shouldn't Sling provide some
help and call the right ResourceProvider for you?
best regards
mike
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: Wednesday, July 18, 2012 9:31 AM
> To: dev@sling.apache.org
> Subject: [RT] API for modifying resources
>
> Hi,
>
> I'm currently working on CRUD support for Sling based on the resource
> API. Current trunk contains already a version of it.
> I'm wondering what the best api for modifying resources is.
>
> Right now, the idea is to adapt a resource to ModifiableValueMap which
> is an extension of the ValueMap. Like the PersistableValueMap this map
> collects all changes internally. It provides an update() method which
> pushes the changes into the transient persistence layer (e.g. jcr
> session). A call to the resource resolver finally persists all
> transient changes (let's forget about different resource providers and
> transactions for now)
> This approach has the advantage to reuse the map interface to change
> values, no exceptions are thrown on put and remove. - but it requires
> to additional calls, update on the map and commit on the resource
> resolver to get the changes persisted.
>
> I thought of changing this and push each change directly into the
> transient store, so a call to put() or remove() on the map is directly
> pushed through - this avoids the extra call to update(), however put()
> and remove() have no checked exceptions declared. So we can either
> throw undeclared exceptions (which I think is not really a good idea
> in this case) or defer exception throwing until the commit call on the
> resource resolver. But obviously this gets nasty if e.g. a put() is
> not successful, doesn't throw an exception and one is doing a get on
> the same property etc.
>
> So, final solution would be to add special methods like set and delete
> which might throw PersistenceException - and avoid reuse of modifying
> methods from the map interface. Simpler to use compared to the current
> version in trunk but additional methods.
>
> Right now I'm undecided between the first and the last solution - with
> a slight preference of the current version from trunk.
>
> But maybe there are other/better options?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jul 31, 2012 at 10:58 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I've changed the implementation and now to change a resource, you
> adapt it to a ModifiableValueMap change the properties through
> put/putAll/remove, this goes into the transient space and then finally
> you call ResourceResolver#commit.
>
> I think this is a nice and easy solution....
Agreed, looks good to me!
-Bertrand
Re: [RT] API for modifying resources
Posted by Carsten Ziegeler <cz...@apache.org>.
Just an update on update :)
I've changed the implementation and now to change a resource, you
adapt it to a ModifiableValueMap change the properties through
put/putAll/remove, this goes into the transient space and then finally
you call ResourceResolver#commit.
I think this is a nice and easy solution.
In general my suggestion is that we play around with this api for a
little time now and see how it feels
Carsten
2012/7/31 Mike Müller <mi...@mysign.ch>:
>> -----Original Message-----
>> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
>> Sent: Tuesday, July 31, 2012 9:54 AM
>> To: dev@sling.apache.org
>> Subject: Re: [RT] API for modifying resources
>>
>> On Tue, Jul 31, 2012 at 9:48 AM, Mike Müller <mi...@mysign.ch> wrote:
>> > ...that's what I meant in my post before, that update AND commit is
>> > a little complicated. On the other hand, if we want to introduce a transient
>> > space as Carsten proposes, there have to be two different methods....
>>
>> Really? What's wrong with ModifiableValueMap.put(..) and similar
>> methods calling "save to transient space" behind the scenes?
>>
>> You'd then just need commit() or something to make changes persistent.
>
> That sounds okay form me and will make update obsolete.
>
> best regards
> mike
--
Carsten Ziegeler
cziegeler@apache.org
RE: [RT] API for modifying resources
Posted by Mike Müller <mi...@mysign.ch>.
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: Tuesday, July 31, 2012 9:54 AM
> To: dev@sling.apache.org
> Subject: Re: [RT] API for modifying resources
>
> On Tue, Jul 31, 2012 at 9:48 AM, Mike Müller <mi...@mysign.ch> wrote:
> > ...that's what I meant in my post before, that update AND commit is
> > a little complicated. On the other hand, if we want to introduce a transient
> > space as Carsten proposes, there have to be two different methods....
>
> Really? What's wrong with ModifiableValueMap.put(..) and similar
> methods calling "save to transient space" behind the scenes?
>
> You'd then just need commit() or something to make changes persistent.
That sounds okay form me and will make update obsolete.
best regards
mike
Re: [RT] API for modifying resources
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jul 31, 2012 at 9:48 AM, Mike Müller <mi...@mysign.ch> wrote:
> ...that's what I meant in my post before, that update AND commit is
> a little complicated. On the other hand, if we want to introduce a transient
> space as Carsten proposes, there have to be two different methods....
Really? What's wrong with ModifiableValueMap.put(..) and similar
methods calling "save to transient space" behind the scenes?
You'd then just need commit() or something to make changes persistent.
-Bertrand
RE: [RT] API for modifying resources
Posted by Mike Müller <mi...@mysign.ch>.
> > Hi,
> >
> > I'm currently working on CRUD support for Sling based on the resource
> > API. Current trunk contains already a version of it.
> > I'm wondering what the best api for modifying resources is.
> >
> > Right now, the idea is to adapt a resource to ModifiableValueMap which
> > is an extension of the ValueMap. Like the PersistableValueMap this map
> > collects all changes internally. It provides an update() method which
> > pushes the changes into the transient persistence layer (e.g. jcr
> > session). A call to the resource resolver finally persists all
> > transient changes (let's forget about different resource providers and
> > transactions for now)
> > This approach has the advantage to reuse the map interface to change
> > values, no exceptions are thrown on put and remove. - but it requires
> > to additional calls, update on the map and commit on the resource
> > resolver to get the changes persisted.
>
> This "second level of indirection" -- calling update and then commit -- sounds like
> overhead.
Actually that's what I meant in my post before, that update AND commit is
a little complicated. On the other hand, if we want to introduce a transient
space as Carsten proposes, there have to be two different methods.
My suggestion was to only introduce update directly on the ModifiableValueMap
at the moment (and therefore no transient space or transactions).
In this case to update a Resource, only a Resource is needed, which would
the handling make easier. Or we cancel the update Method and only introduce
the ResourceResolver#commit which would it make easier to add transactions
in the future.
Or go with both as in the trunk by now...
best regards
mike
Re: [RT] API for modifying resources
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/7/30 Felix Meschberger <fm...@adobe.com>:
>>
>> 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.
Good point, if I look at the jcr value map implementation it is very
unlikely that put fails - and the same is true for other
implementations.
Ok, this convinced me :) Let's go the nicer way.
> Ok.
>
> For an FS provider the files and folders could be created in a temporary space and moved into the final location on commit.
Yes, and that should be easy to implement as well.
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 30.07.2012 um 12:53 schrieb Carsten Ziegeler:
> 2012/7/30 Felix Meschberger <fm...@adobe.com>:
>
>>
>> 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
> cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jul 30, 2012 at 12:53 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> 2012/7/30 Felix Meschberger <fm...@adobe.com>:
...
>> * Any persistence exceptions are wrapped into one of the defined
>> runtime exceptions (e.g. ValueFormatException wrapped into ClassCastException)
...
> ...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....
You could make it less surprising by throwing a SlingCrudException (or
whatever name fits), which extends IllegalStateException.
-Bertrand
Re: [RT] API for modifying resources
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/7/30 Felix Meschberger <fm...@adobe.com>:
>
> 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
cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Thanks for the hard work on this important topic.
Am 18.07.2012 um 09:30 schrieb Carsten Ziegeler:
> Hi,
>
> I'm currently working on CRUD support for Sling based on the resource
> API. Current trunk contains already a version of it.
> I'm wondering what the best api for modifying resources is.
>
> Right now, the idea is to adapt a resource to ModifiableValueMap which
> is an extension of the ValueMap. Like the PersistableValueMap this map
> collects all changes internally. It provides an update() method which
> pushes the changes into the transient persistence layer (e.g. jcr
> session). A call to the resource resolver finally persists all
> transient changes (let's forget about different resource providers and
> transactions for now)
> This approach has the advantage to reuse the map interface to change
> values, no exceptions are thrown on put and remove. - but it requires
> to additional calls, update on the map and commit on the resource
> resolver to get the changes persisted.
This "second level of indirection" -- calling update and then commit -- sounds like overhead.
>
> I thought of changing this and push each change directly into the
> transient store, so a call to put() or remove() on the map is directly
> pushed through - this avoids the extra call to update(), however put()
> and remove() have no checked exceptions declared. So we can either
> throw undeclared exceptions (which I think is not really a good idea
> in this case) or defer exception throwing until the commit call on the
> resource resolver. But obviously this gets nasty if e.g. a put() is
> not successful, doesn't throw an exception and one is doing a get on
> the same property etc.
According to the Map interface, we can throw any of UnsupportedOperationException, ClassCastException, NullPointerException, IllegalArgumentException wrapping the actual underlying cause. While this is not part of the ValueMap interface itself it is inherited from the Map interface.
So the exception handling part of the problem could really be solved IMHO.
The other part of the problem as noted by Tobias B. is very important, too: There are live set views on the Map (keys, values, entries (and their Entry objects)), which also have update methods to be handled. This might be solved by having these views be Unmodifiable.. (similar to what Collections.UnmodifiableMap does).
>
> So, final solution would be to add special methods like set and delete
> which might throw PersistenceException - and avoid reuse of modifying
> methods from the map interface. Simpler to use compared to the current
> version in trunk but additional methods.
I think that is not required when considering wrapping persistence exceptions into one of the runtime exceptions declared by the Map interface.
>
> Right now I'm undecided between the first and the last solution - with
> a slight preference of the current version from trunk.
>
> But maybe there are other/better options?
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 ?
Follow-up questions: Do all ModifyingResourceProvider implementations have to provide a transient space ? I am thinking of a Filesystem based implementation.
I will have some more general comments on the current trunk in a separate thread.
Regards
Felix
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 21.07.2012 um 08:49 schrieb Tobias Bocanegra:
> Hi,
> I like the 2nd idea better, as you get direct feedback when operating
> on the map, e.g. if a property can't be set.
>
> however, the writing map methods are:
> - put()
> - putAll()
> - remove()
> - clear()
>
> and I would throw a IllegalStateException if they fail (clear() will
> most likely never succeed, since jcr:primaryType is not deletable :-)
>
> and there are also indirect operations that modify the map:
> - keySet().* writing ops
> - values().* writing ops
> - entrySet().* wrirting ops
>
> so given the complexity, I think it's better to delay the writeback
> until update() is called. You loose the fine granular information of
> what failed, but in my experience the user cannot really do anything
> when e.g. a setProperty() fails, but just retry.
> (and there is stil the workaround to update() after each put())
>
> Additionally, the PersistException (or whatever update() throws) could
> have a 'getFailedOperations()' method that list the failed operations.
Sounds like a good idea.
Regards
Felix
>
> regards, toby
>
> On Wed, Jul 18, 2012 at 12:30 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> I'm currently working on CRUD support for Sling based on the resource
>> API. Current trunk contains already a version of it.
>> I'm wondering what the best api for modifying resources is.
>>
>> Right now, the idea is to adapt a resource to ModifiableValueMap which
>> is an extension of the ValueMap. Like the PersistableValueMap this map
>> collects all changes internally. It provides an update() method which
>> pushes the changes into the transient persistence layer (e.g. jcr
>> session). A call to the resource resolver finally persists all
>> transient changes (let's forget about different resource providers and
>> transactions for now)
>> This approach has the advantage to reuse the map interface to change
>> values, no exceptions are thrown on put and remove. - but it requires
>> to additional calls, update on the map and commit on the resource
>> resolver to get the changes persisted.
>>
>> I thought of changing this and push each change directly into the
>> transient store, so a call to put() or remove() on the map is directly
>> pushed through - this avoids the extra call to update(), however put()
>> and remove() have no checked exceptions declared. So we can either
>> throw undeclared exceptions (which I think is not really a good idea
>> in this case) or defer exception throwing until the commit call on the
>> resource resolver. But obviously this gets nasty if e.g. a put() is
>> not successful, doesn't throw an exception and one is doing a get on
>> the same property etc.
>>
>> So, final solution would be to add special methods like set and delete
>> which might throw PersistenceException - and avoid reuse of modifying
>> methods from the map interface. Simpler to use compared to the current
>> version in trunk but additional methods.
>>
>> Right now I'm undecided between the first and the last solution - with
>> a slight preference of the current version from trunk.
>>
>> But maybe there are other/better options?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks Tobi,
so I think we'll go with the update() method.
Carsten
2012/7/21 Tobias Bocanegra <tr...@adobe.com>:
> Hi,
> I like the 2nd idea better, as you get direct feedback when operating
> on the map, e.g. if a property can't be set.
>
> however, the writing map methods are:
> - put()
> - putAll()
> - remove()
> - clear()
>
> and I would throw a IllegalStateException if they fail (clear() will
> most likely never succeed, since jcr:primaryType is not deletable :-)
>
> and there are also indirect operations that modify the map:
> - keySet().* writing ops
> - values().* writing ops
> - entrySet().* wrirting ops
>
> so given the complexity, I think it's better to delay the writeback
> until update() is called. You loose the fine granular information of
> what failed, but in my experience the user cannot really do anything
> when e.g. a setProperty() fails, but just retry.
> (and there is stil the workaround to update() after each put())
>
> Additionally, the PersistException (or whatever update() throws) could
> have a 'getFailedOperations()' method that list the failed operations.
>
> regards, toby
>
> On Wed, Jul 18, 2012 at 12:30 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Hi,
>>
>> I'm currently working on CRUD support for Sling based on the resource
>> API. Current trunk contains already a version of it.
>> I'm wondering what the best api for modifying resources is.
>>
>> Right now, the idea is to adapt a resource to ModifiableValueMap which
>> is an extension of the ValueMap. Like the PersistableValueMap this map
>> collects all changes internally. It provides an update() method which
>> pushes the changes into the transient persistence layer (e.g. jcr
>> session). A call to the resource resolver finally persists all
>> transient changes (let's forget about different resource providers and
>> transactions for now)
>> This approach has the advantage to reuse the map interface to change
>> values, no exceptions are thrown on put and remove. - but it requires
>> to additional calls, update on the map and commit on the resource
>> resolver to get the changes persisted.
>>
>> I thought of changing this and push each change directly into the
>> transient store, so a call to put() or remove() on the map is directly
>> pushed through - this avoids the extra call to update(), however put()
>> and remove() have no checked exceptions declared. So we can either
>> throw undeclared exceptions (which I think is not really a good idea
>> in this case) or defer exception throwing until the commit call on the
>> resource resolver. But obviously this gets nasty if e.g. a put() is
>> not successful, doesn't throw an exception and one is doing a get on
>> the same property etc.
>>
>> So, final solution would be to add special methods like set and delete
>> which might throw PersistenceException - and avoid reuse of modifying
>> methods from the map interface. Simpler to use compared to the current
>> version in trunk but additional methods.
>>
>> Right now I'm undecided between the first and the last solution - with
>> a slight preference of the current version from trunk.
>>
>> But maybe there are other/better options?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: [RT] API for modifying resources
Posted by Tobias Bocanegra <tr...@adobe.com>.
Hi,
I like the 2nd idea better, as you get direct feedback when operating
on the map, e.g. if a property can't be set.
however, the writing map methods are:
- put()
- putAll()
- remove()
- clear()
and I would throw a IllegalStateException if they fail (clear() will
most likely never succeed, since jcr:primaryType is not deletable :-)
and there are also indirect operations that modify the map:
- keySet().* writing ops
- values().* writing ops
- entrySet().* wrirting ops
so given the complexity, I think it's better to delay the writeback
until update() is called. You loose the fine granular information of
what failed, but in my experience the user cannot really do anything
when e.g. a setProperty() fails, but just retry.
(and there is stil the workaround to update() after each put())
Additionally, the PersistException (or whatever update() throws) could
have a 'getFailedOperations()' method that list the failed operations.
regards, toby
On Wed, Jul 18, 2012 at 12:30 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I'm currently working on CRUD support for Sling based on the resource
> API. Current trunk contains already a version of it.
> I'm wondering what the best api for modifying resources is.
>
> Right now, the idea is to adapt a resource to ModifiableValueMap which
> is an extension of the ValueMap. Like the PersistableValueMap this map
> collects all changes internally. It provides an update() method which
> pushes the changes into the transient persistence layer (e.g. jcr
> session). A call to the resource resolver finally persists all
> transient changes (let's forget about different resource providers and
> transactions for now)
> This approach has the advantage to reuse the map interface to change
> values, no exceptions are thrown on put and remove. - but it requires
> to additional calls, update on the map and commit on the resource
> resolver to get the changes persisted.
>
> I thought of changing this and push each change directly into the
> transient store, so a call to put() or remove() on the map is directly
> pushed through - this avoids the extra call to update(), however put()
> and remove() have no checked exceptions declared. So we can either
> throw undeclared exceptions (which I think is not really a good idea
> in this case) or defer exception throwing until the commit call on the
> resource resolver. But obviously this gets nasty if e.g. a put() is
> not successful, doesn't throw an exception and one is doing a get on
> the same property etc.
>
> So, final solution would be to add special methods like set and delete
> which might throw PersistenceException - and avoid reuse of modifying
> methods from the map interface. Simpler to use compared to the current
> version in trunk but additional methods.
>
> Right now I'm undecided between the first and the last solution - with
> a slight preference of the current version from trunk.
>
> But maybe there are other/better options?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org