[dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support for workspaces

[Randall Hauch (JIRA)]

    [ https://jira.jboss.org/jira/browse/DNA-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12452463#action_12452463 ] 

Randall Hauch commented on DNA-281:
-----------------------------------

Several different options were investigated:
1) Adding the name of the workspace to Location, allowing existing requests to operate against workspaces.  This may have involved fewer changes, since the Location object would be doing the work of maintaining the workspace reference.  However, considering that Location objects are used with every request and in every response, the additional size of the Location objects (many with the same workspace) would also make this option more memory intensive.  Also, some existing requests that take two Locations (e.g., move) may not make much sense if each Location had a different workspace. (The JCR spec does not define moving between workspaces, although copying and cloning are defined).  This option also complicates the Graph API by increasing the number of ways in which a node can be specified.

2) Add the name of the workspace to each Request (or in some cases like CopyBranchRequest, the names of the multiple workspaces).  This option has the advantage of tracking the workspace(s) only on the requests and not in the results, as the requests are really a transient representation of an operation, whereas the results of the requests (e.g., Locations, Property, values, etc.) would not contain the workspace references and would not increase in memory footprint.  This is considerable, as there would often be orders of magnitude fewer workspaces than there are nodes and Locations.  This design option also fits in a little better with the new types of requests needed to get the list of workspaces, create new workspaces, clone workspaces, or delete workspaces.

The design started with Option 1 since it was thought to be least intrusive and most straightforward, but this initial implementation highlighted the disadvantages.  Option 2 was then prototyped, and although there were more changes, option 2 appeared to be a more natural design that seemed to work better.  Therefore, option 2 was chosen for the implementation.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira