You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Justin Edelson <ju...@gmail.com> on 2010/06/14 17:30:03 UTC
versioning support in POST servlet
I'm starting to hack on the post servlet to get it to support JCR
versioning. It is actually much simpler than I thought it would be.
Which leads me to believe I'm missing something big :)
Would appreciate any comments/feedback:
http://codereview.appspot.com/1690041
Thanks,
Justin
Re: versioning support in POST servlet
Posted by Justin Edelson <ju...@gmail.com>.
Here's take 2 of the implementation: http://codereview.appspot.com/1710045
In general, any checkouts done in the context of a post will be checked
in at the end of the request. This can be disabled on a per-request
basis by passing :skipCheckIn=true.
Very important note - if the ModifyOperation encounters a node which is
already checked out, this node will *not* be checked back in at the end
of the request.
So it should work with whatever has been implemented already in Sakai.
I've also implemented separate checkout and checkin operations and added
support within ModificationType for these new modification types.
Justin
On 6/14/10 5:33 PM, Ian Boston wrote:
>
> On 14 Jun 2010, at 13:23, Justin Edelson wrote:
>
>> On 6/14/10 3:02 PM, Ian Boston wrote:
>>> A quick question,
>>>
>>> Does every modification create a new version or is versioning only enabled if a parameter to request a new version is set ?
>> Right now, every request does a checkin upon completion for any node
>> which was checked out during the request. So theoretically it would work
>> with your current code as the checkout is being done by a different
>> servlet (at least that's what it sounds like).
>
> The concern is we have 100s of updates to some nodes and we don't want to create new versions of every update, only one or two. If we cant turn off creating new versions on every update, we are going to be in trouble.
>
> so what we need is checkin+checkout if and only if the parameter :save=1 is set ?
>
> or something like that.
>
>
>>
>>>
>>> We have some very active modifications were we don't want versions, unless we explicitly request it.
>>> We also have a separate servlet that we use for saving versions and listing them.
>>>
>>> The code looks right, although I am not clear if it leaves the node in a checked out state ? If it leaves it in a checked in state, its going to be read only (iirc)
>> Any node which was checked in before the operation is run should be
>> checked in when it is finished. This seems like the right default
>> behavior to me, but I'm open to discussing this as well as providing
>> separate operations for explicit checkout and checkin.
>>
>> It would be natural once the post servlet supports versioning to pull in
>> the Sakai GET versioning servlets, assuming you're ok with that.
>
> Yes, probably, reducing the number of servlets, classloaders and code base is always a good thing.
>
> Ian
>
>
>>
>> Justin
>>
>>>
>>> Ian
>>>
>>>
>>> On 14 Jun 2010, at 09:30, Justin Edelson wrote:
>>>
>>>> I'm starting to hack on the post servlet to get it to support JCR
>>>> versioning. It is actually much simpler than I thought it would be.
>>>> Which leads me to believe I'm missing something big :)
>>>>
>>>> Would appreciate any comments/feedback:
>>>> http://codereview.appspot.com/1690041
>>>>
>>>> Thanks,
>>>> Justin
>>>
>>
>
Re: versioning support in POST servlet
Posted by Ian Boston <ie...@tfd.co.uk>.
On 14 Jun 2010, at 13:23, Justin Edelson wrote:
> On 6/14/10 3:02 PM, Ian Boston wrote:
>> A quick question,
>>
>> Does every modification create a new version or is versioning only enabled if a parameter to request a new version is set ?
> Right now, every request does a checkin upon completion for any node
> which was checked out during the request. So theoretically it would work
> with your current code as the checkout is being done by a different
> servlet (at least that's what it sounds like).
The concern is we have 100s of updates to some nodes and we don't want to create new versions of every update, only one or two. If we cant turn off creating new versions on every update, we are going to be in trouble.
so what we need is checkin+checkout if and only if the parameter :save=1 is set ?
or something like that.
>
>>
>> We have some very active modifications were we don't want versions, unless we explicitly request it.
>> We also have a separate servlet that we use for saving versions and listing them.
>>
>> The code looks right, although I am not clear if it leaves the node in a checked out state ? If it leaves it in a checked in state, its going to be read only (iirc)
> Any node which was checked in before the operation is run should be
> checked in when it is finished. This seems like the right default
> behavior to me, but I'm open to discussing this as well as providing
> separate operations for explicit checkout and checkin.
>
> It would be natural once the post servlet supports versioning to pull in
> the Sakai GET versioning servlets, assuming you're ok with that.
Yes, probably, reducing the number of servlets, classloaders and code base is always a good thing.
Ian
>
> Justin
>
>>
>> Ian
>>
>>
>> On 14 Jun 2010, at 09:30, Justin Edelson wrote:
>>
>>> I'm starting to hack on the post servlet to get it to support JCR
>>> versioning. It is actually much simpler than I thought it would be.
>>> Which leads me to believe I'm missing something big :)
>>>
>>> Would appreciate any comments/feedback:
>>> http://codereview.appspot.com/1690041
>>>
>>> Thanks,
>>> Justin
>>
>
Re: versioning support in POST servlet
Posted by Justin Edelson <ju...@gmail.com>.
On 6/14/10 3:02 PM, Ian Boston wrote:
> A quick question,
>
> Does every modification create a new version or is versioning only enabled if a parameter to request a new version is set ?
Right now, every request does a checkin upon completion for any node
which was checked out during the request. So theoretically it would work
with your current code as the checkout is being done by a different
servlet (at least that's what it sounds like).
>
> We have some very active modifications were we don't want versions, unless we explicitly request it.
> We also have a separate servlet that we use for saving versions and listing them.
>
> The code looks right, although I am not clear if it leaves the node in a checked out state ? If it leaves it in a checked in state, its going to be read only (iirc)
Any node which was checked in before the operation is run should be
checked in when it is finished. This seems like the right default
behavior to me, but I'm open to discussing this as well as providing
separate operations for explicit checkout and checkin.
It would be natural once the post servlet supports versioning to pull in
the Sakai GET versioning servlets, assuming you're ok with that.
Justin
>
> Ian
>
>
> On 14 Jun 2010, at 09:30, Justin Edelson wrote:
>
>> I'm starting to hack on the post servlet to get it to support JCR
>> versioning. It is actually much simpler than I thought it would be.
>> Which leads me to believe I'm missing something big :)
>>
>> Would appreciate any comments/feedback:
>> http://codereview.appspot.com/1690041
>>
>> Thanks,
>> Justin
>
Re: versioning support in POST servlet
Posted by Ian Boston <ie...@tfd.co.uk>.
A quick question,
Does every modification create a new version or is versioning only enabled if a parameter to request a new version is set ?
We have some very active modifications were we don't want versions, unless we explicitly request it.
We also have a separate servlet that we use for saving versions and listing them.
The code looks right, although I am not clear if it leaves the node in a checked out state ? If it leaves it in a checked in state, its going to be read only (iirc)
Ian
On 14 Jun 2010, at 09:30, Justin Edelson wrote:
> I'm starting to hack on the post servlet to get it to support JCR
> versioning. It is actually much simpler than I thought it would be.
> Which leads me to believe I'm missing something big :)
>
> Would appreciate any comments/feedback:
> http://codereview.appspot.com/1690041
>
> Thanks,
> Justin
Re: versioning support in POST servlet
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I have now changed the default for the autoCheckout property of
versioning. This is now "false". I did not change the other property
default values.
Regards
Felix
On 23.09.2010 16:13, Felix Meschberger wrote:
> Hi,
>
> Am 23.09.2010 15:50, schrieb Justin Edelson:
>> Is the problem you're referring to SLING-1797 or something larger?
>
> This is just the issue to track the change of the default.
>
> What I have in mind is effectively the case where something now
> succeeds, which used to fail: modifying a checked-in node.
>
> Regards
> Felix
>
>>
>> As far as I know, the only non-backwards-compatible change is that
>> something[1] which would otherwise fail now succeeds. Everything else
>> that was done in SLING-1573 was (or at least should be)
>> backwards-compatible.
>>
>> To me, this type of non-backwards-compatible change is acceptable, but
>> can understand if I'm in the minority on that.
>>
>> Justin
>>
>> [1] modifying a versionable and checked-in node
>>
>> On 9/23/10 3:13 AM, Felix Meschberger wrote:
>>> Hi,
>>>
>>> I just stumbled on a problem we have internally caused by the new
>>> versioning support; so I would like to pick this up again.
>>>
>>> As of SLING-1573 [1] a modification operation by default tries to
>>> checkout and checkin if required. In fact the issue also notes that this
>>> is not strictly backwards compatible.
>>>
>>> IMHO we should really strive for being backwards compatible if at all
>>> possible, particularly in a case where "per-default-enablement" of a new
>>> feature can be done with simple configuration provision.
>>>
>>> Therefore I suggest we should change the default to being "no versioning
>>> at all" (tracked with SLING-1796 [2]).
>>>
>>> Regards
>>> Felix
>>>
>>> [1] https://issues.apache.org/jira/browse/SLING-1573
>>> [2] https://issues.apache.org/jira/browse/SLING-1796
>>>
>>> Am 14.06.2010 17:30, schrieb Justin Edelson:
>>>> I'm starting to hack on the post servlet to get it to support JCR
>>>> versioning. It is actually much simpler than I thought it would be.
>>>> Which leads me to believe I'm missing something big :)
>>>>
>>>> Would appreciate any comments/feedback:
>>>> http://codereview.appspot.com/1690041
>>>>
>>>> Thanks,
>>>> Justin
>>>>
>>
>>
Re: versioning support in POST servlet
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am 23.09.2010 15:50, schrieb Justin Edelson:
> Is the problem you're referring to SLING-1797 or something larger?
This is just the issue to track the change of the default.
What I have in mind is effectively the case where something now
succeeds, which used to fail: modifying a checked-in node.
Regards
Felix
>
> As far as I know, the only non-backwards-compatible change is that
> something[1] which would otherwise fail now succeeds. Everything else
> that was done in SLING-1573 was (or at least should be)
> backwards-compatible.
>
> To me, this type of non-backwards-compatible change is acceptable, but
> can understand if I'm in the minority on that.
>
> Justin
>
> [1] modifying a versionable and checked-in node
>
> On 9/23/10 3:13 AM, Felix Meschberger wrote:
>> Hi,
>>
>> I just stumbled on a problem we have internally caused by the new
>> versioning support; so I would like to pick this up again.
>>
>> As of SLING-1573 [1] a modification operation by default tries to
>> checkout and checkin if required. In fact the issue also notes that this
>> is not strictly backwards compatible.
>>
>> IMHO we should really strive for being backwards compatible if at all
>> possible, particularly in a case where "per-default-enablement" of a new
>> feature can be done with simple configuration provision.
>>
>> Therefore I suggest we should change the default to being "no versioning
>> at all" (tracked with SLING-1796 [2]).
>>
>> Regards
>> Felix
>>
>> [1] https://issues.apache.org/jira/browse/SLING-1573
>> [2] https://issues.apache.org/jira/browse/SLING-1796
>>
>> Am 14.06.2010 17:30, schrieb Justin Edelson:
>>> I'm starting to hack on the post servlet to get it to support JCR
>>> versioning. It is actually much simpler than I thought it would be.
>>> Which leads me to believe I'm missing something big :)
>>>
>>> Would appreciate any comments/feedback:
>>> http://codereview.appspot.com/1690041
>>>
>>> Thanks,
>>> Justin
>>>
>
>
Re: versioning support in POST servlet
Posted by Justin Edelson <ju...@gmail.com>.
Is the problem you're referring to SLING-1797 or something larger?
As far as I know, the only non-backwards-compatible change is that
something[1] which would otherwise fail now succeeds. Everything else
that was done in SLING-1573 was (or at least should be)
backwards-compatible.
To me, this type of non-backwards-compatible change is acceptable, but
can understand if I'm in the minority on that.
Justin
[1] modifying a versionable and checked-in node
On 9/23/10 3:13 AM, Felix Meschberger wrote:
> Hi,
>
> I just stumbled on a problem we have internally caused by the new
> versioning support; so I would like to pick this up again.
>
> As of SLING-1573 [1] a modification operation by default tries to
> checkout and checkin if required. In fact the issue also notes that this
> is not strictly backwards compatible.
>
> IMHO we should really strive for being backwards compatible if at all
> possible, particularly in a case where "per-default-enablement" of a new
> feature can be done with simple configuration provision.
>
> Therefore I suggest we should change the default to being "no versioning
> at all" (tracked with SLING-1796 [2]).
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-1573
> [2] https://issues.apache.org/jira/browse/SLING-1796
>
> Am 14.06.2010 17:30, schrieb Justin Edelson:
>> I'm starting to hack on the post servlet to get it to support JCR
>> versioning. It is actually much simpler than I thought it would be.
>> Which leads me to believe I'm missing something big :)
>>
>> Would appreciate any comments/feedback:
>> http://codereview.appspot.com/1690041
>>
>> Thanks,
>> Justin
>>
Re: versioning support in POST servlet
Posted by Justin Edelson <ju...@gmail.com>.
There are actually three different "switches"
1) Checkin new versionable nodes - defaults to false
2) Auto Checkout - defaults to true
3) Auto Checkin - defaults to true
#1 originally defaulted to true, but this was a significant
backwards-compatibility issue.
AFAICT, Felix is talking about the latter two.
Justin
On 9/23/10 9:49 AM, Ian Boston wrote:
> IIRC the thread at the time discussed making versioning non default.
> I think there is a configuration switch that allows it to be non default, but the default for that switch is "versioning on", ie checkin checkout.
> Ian
>
> On 23 Sep 2010, at 15:13, Felix Meschberger wrote:
>
>> Hi,
>>
>> I just stumbled on a problem we have internally caused by the new
>> versioning support; so I would like to pick this up again.
>>
>> As of SLING-1573 [1] a modification operation by default tries to
>> checkout and checkin if required. In fact the issue also notes that this
>> is not strictly backwards compatible.
>>
>> IMHO we should really strive for being backwards compatible if at all
>> possible, particularly in a case where "per-default-enablement" of a new
>> feature can be done with simple configuration provision.
>>
>> Therefore I suggest we should change the default to being "no versioning
>> at all" (tracked with SLING-1796 [2]).
>>
>> Regards
>> Felix
>>
>> [1] https://issues.apache.org/jira/browse/SLING-1573
>> [2] https://issues.apache.org/jira/browse/SLING-1796
>>
>> Am 14.06.2010 17:30, schrieb Justin Edelson:
>>> I'm starting to hack on the post servlet to get it to support JCR
>>> versioning. It is actually much simpler than I thought it would be.
>>> Which leads me to believe I'm missing something big :)
>>>
>>> Would appreciate any comments/feedback:
>>> http://codereview.appspot.com/1690041
>>>
>>> Thanks,
>>> Justin
>>>
>
Re: versioning support in POST servlet
Posted by Ian Boston <ie...@tfd.co.uk>.
IIRC the thread at the time discussed making versioning non default.
I think there is a configuration switch that allows it to be non default, but the default for that switch is "versioning on", ie checkin checkout.
Ian
On 23 Sep 2010, at 15:13, Felix Meschberger wrote:
> Hi,
>
> I just stumbled on a problem we have internally caused by the new
> versioning support; so I would like to pick this up again.
>
> As of SLING-1573 [1] a modification operation by default tries to
> checkout and checkin if required. In fact the issue also notes that this
> is not strictly backwards compatible.
>
> IMHO we should really strive for being backwards compatible if at all
> possible, particularly in a case where "per-default-enablement" of a new
> feature can be done with simple configuration provision.
>
> Therefore I suggest we should change the default to being "no versioning
> at all" (tracked with SLING-1796 [2]).
>
> Regards
> Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-1573
> [2] https://issues.apache.org/jira/browse/SLING-1796
>
> Am 14.06.2010 17:30, schrieb Justin Edelson:
>> I'm starting to hack on the post servlet to get it to support JCR
>> versioning. It is actually much simpler than I thought it would be.
>> Which leads me to believe I'm missing something big :)
>>
>> Would appreciate any comments/feedback:
>> http://codereview.appspot.com/1690041
>>
>> Thanks,
>> Justin
>>
Re: versioning support in POST servlet
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I just stumbled on a problem we have internally caused by the new
versioning support; so I would like to pick this up again.
As of SLING-1573 [1] a modification operation by default tries to
checkout and checkin if required. In fact the issue also notes that this
is not strictly backwards compatible.
IMHO we should really strive for being backwards compatible if at all
possible, particularly in a case where "per-default-enablement" of a new
feature can be done with simple configuration provision.
Therefore I suggest we should change the default to being "no versioning
at all" (tracked with SLING-1796 [2]).
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-1573
[2] https://issues.apache.org/jira/browse/SLING-1796
Am 14.06.2010 17:30, schrieb Justin Edelson:
> I'm starting to hack on the post servlet to get it to support JCR
> versioning. It is actually much simpler than I thought it would be.
> Which leads me to believe I'm missing something big :)
>
> Would appreciate any comments/feedback:
> http://codereview.appspot.com/1690041
>
> Thanks,
> Justin
>