[ https://issues.apache.org/jira/browse/SLING-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14280893#comment-14280893 ]
Tomek Rękawek edited comment on SLING-4318 at 1/16/15 10:10 PM: ---------------------------------------------------------------- Right now, Sling RESTful API provides checkin and checkout operations. Following sequence of curls will create a new version of the /content/test node: {code} curl -F :operation=checkout localhost:4502/content/test curl -F property=newValue localhost:4502/content/test curl -F :operation=checkin localhost:4502/content/test {code} There are also :autoCheckout and :autoCheckin parameters that allows to automatically checkout versionable nodes before modification and check them in after modification. Above curls could be rewritten as: {code} curl -F :autoCheckin=true -F :autoCheckout=true -F property=newValue localhost:4502/content/test {code} These parameters could be use implicitly if the Sling is properly configured \[1]. In the discussion \[2] Bertrand suggested creating servlets that allows to manage versions. Servlets should be bound to a pre-defined selector, like {{V}}. I think the existing checkin/checkout operations covers creating new versions pretty well. I think the most important operations that we miss are: 1. listing versions, 2. getting the base (current) version number, 3. restoring a version, 4. presenting different version of the resource (as in SLING-848). There are also merges and activity-related operations, but they seem to be quite complicated and I'm not sure if the RESTful API is a good place for them. Please find my proposal below: {code} # 1+2. Listing versions & getting the base version curl -X GET localhost:4502/content/test.V.json # Result: { "jcr:rootVersion": { "created": "Mon Sep 29 2014 12:08:56 GMT+0200", "successors": [ "1.0" ], "baseVersion": false }, "1.0": { "created": "Mon Sep 29 2014 12:08:57 GMT+0200", "successors": [ "1.1", "1.0.0" ], "baseVersion": false }, "1.1": { "created": "Mon Sep 29 2014 12:08:58 GMT+0200", "successors": [], "baseVersion": false }, "1.0.0": { "created": "Mon Sep 29 2014 12:08:59 GMT+0200", "successors": [], "baseVersion": true } } # 3. Restoring a version curl -X POST -F :operation=restoreVersion -F :version=1.0 localhost:4502/content/test # Presenting different version of the resource as in SLING-848 curl -X GET localhost:4502/content/test.html;v=1.1 curl -X GET localhost:4502/content/test;v='1.1'.html {code} Ad. 1 - Actually, this is the only place where we use the {{V}} selector. Maybe we could replace it with {{versions}}? Ad. 3 - I know that the parameters in the restoreVersion operation are not beautiful, but they are consistent with current Sling operations (like move, copy, delete, etc.) \[3]. I'd love to have some feedback from more experienced Sling devs. \[1] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#versionable-node-support \[2] http://thread.gmane.org/gmane.comp.apache.sling.user/1610 \[3] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations was (Author: tomek.rekawek): Right now, Sling RESTful API provides checkin and checkout operations. Following sequence of curls will create a new version of the /content/test node: {code} curl -F :operation=checkout localhost:4502/content/test curl -F property=newValue localhost:4502/content/test curl -F :operation=checkin localhost:4502/content/test {code} There are also :autoCheckout and :autoCheckin parameters that allows to automatically checkout versionable nodes before modification and check them in after modification. Above curls could be rewritten as: {code} curl -F :autoCheckin=true -F :autoCheckout=true -F property=newValue localhost:4502/content/test {code} These parameters could be use implicitly if the Sling is properly configured \[1]. In the discussion \[2] Bertrand suggested creating servlets that allows to manage versions. Servlets should be bound to a pre-defined selector, like {{V}}. I think the existing checkin/checkout operations covers creating new versions pretty well. I think the most important operations that we miss are: 1. listing versions, 2. getting the base (current) version number, 3. restoring a version, 4. presenting different version of the resource (as in SLING-848). There are also merges and activity-related operations, but they seem to be quite complicated and I'm not sure if the RESTful API is a good place for them. Please find my proposal below: {code} # 1+2. Listing versions & getting the base version curl -X GET localhost:4502/content/test.V.json # Result: { "jcr:rootVersion": { "created": "Mon Sep 29 2014 12:08:56 GMT+0200", "label": "successors": [ "1.0" ], "baseVersion": false }, "1.0": { "created": "Mon Sep 29 2014 12:08:57 GMT+0200", "successors": [ "1.1", "1.0.0" ], "baseVersion": false }, "1.1": { "created": "Mon Sep 29 2014 12:08:58 GMT+0200", "successors": [], "baseVersion": false }, "1.0.0": { "created": "Mon Sep 29 2014 12:08:59 GMT+0200", "successors": [], "baseVersion": true } } # 3. Restoring a version curl -X POST -F :operation=restoreVersion -F :version=1.0 localhost:4502/content/test # Presenting different version of the resource as in SLING-848 curl -X GET localhost:4502/content/test.html;v=1.1 curl -X GET localhost:4502/content/test;v='1.1'.html {code} Ad. 1 - Actually, this is the only place where we use the {{V}} selector. Maybe we could replace it with {{versions}}? Ad. 3 - I know that the parameters in the restoreVersion operation are not beautiful, but they are consistent with current Sling operations (like move, copy, delete, etc.) \[3]. I'd love to have some feedback from more experienced Sling devs. \[1] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#versionable-node-support \[2] http://thread.gmane.org/gmane.comp.apache.sling.user/1610 \[3] http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations > Sling resource API does not expose any versioning features - bounty offered. > ---------------------------------------------------------------------------- > > Key: SLING-4318 > URL: https://issues.apache.org/jira/browse/SLING-4318 > Project: Sling > Issue Type: New Feature > Components: Documentation, JCR, Servlets > Affects Versions: Servlets Resolver 2.3.8 > Environment: N/A > Reporter: Bruce Edge > Labels: api, crud, servlet-api, versioning, versions > > The javax.jcr.version.VersionManager is not exposed in the sling resource API: > http://thread.gmane.org/gmane.comp.apache.sling.user/1610 > My company is interested in paying for this development. Please contact if > interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)