[ https://jira.jboss.org/jira/browse/DNA-281?page=com.atlassian.jira.plugin... ] 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. -- 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

[ https://jira.jboss.org/jira/browse/DNA-281?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-281: ----------------------------------- Each connector can choose to support workspaces in a couple of different ways. The connector framework supports the ability to discover the workspaces that are available in a source (or, rather, that are available to the supplied ExecutionContext). In general, the connector would simply return the set of names of existing workspaces, where "existing" means something meaningful to the connector. For example, the JPA Store connector allows defining on the source instance the names of some "predefined" workspaces; these workspaces don't need to be created by the client, becuase the connector always behaves as though those workspaces exist, even if they haven't yet been accessed or initialized. The connector framework also supports the notion of a default workspace. Basically, this is simply a way of allowing a connector to say which workspace should be used if none is specified by the client. However, all requests require a non-null workspace name, with one exception: the VerifyWorkspaceRequest is intended to allow the client to verify that a workspace exists. If the name of the workspace is null, the connector is free to respond with an error or to choose an existing workspace to use. The ability to create new workspaces is defined as a new connector capability, so it's possible for connector implementations to not support creating new workspaces and to simply define the existing workspaces that are available. The SVN connector is one example that might make use of this approach, since the workspaces might be defined by the (existing) branches and tags. (Although branching could be implemented via cloning of a workspace, but this is probably beyond what's needed/desired.) A connector implementation can combine these characteristics to produce a wide range of support. For example, a connector that doesn't really support workspaces really supports just one (which should also be the default) and doesn't support creating new workspaces, cloning workspaces, or destroying existing workspaces. On the other hand, a connector could support multiple workspaces and even allow the client to define new or cloned workspaces. Or, as with the SVN connector, the connector may support multiple workspaces but may not allow clients creating, cloning or destroying 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

[ https://jira.jboss.org/jira/browse/DNA-281?page=com.atlassian.jira.plugin... ] Randall Hauch resolved DNA-281. ------------------------------- Resolution: Done Implemented the changes to support workspaces in connectors. This involved a lot of changes, including all connectors, the Graph API (and implementation), and all uses of the graph API (including a lot of test cases). The SimpleRepositorySource that was available in dna-graph/src/java/test was removed because it started to mirror the code that is in the InMemoryRepositorySource (which is now in dna-graph). This affected quite a few tests cases. This change also made apparent a couple of issues with the current federation code. These problems require more in-depth changes and will be done next, but shouldn't be mixed with this set of changes. This also has implications for several higher-level projects (dna-jcr, getting started examples) that use the connector. Therefore, these projects were temporarily removed and will be added back in shortly. -- 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