In a collaborative modelling environment, there is expected to be multiple users accessing, creating and editing objects (nodes and properties) within a given Komodo Repository.

In our initial Web UI, Data Service Builder, we are partitioning the repository to give each user a "workspace" for their particular Data Services and Sources (i.e. VDBs).

This document is intended to facilitate discussion around the design, management and use cases for a user's workspace.

Use-cases

1. User wants to create 2 or more parallel Data Services for different purposes
   • User 1 is OK with both DS's in a list
   • User 2 wants to managed each DS in it's own "project" or category [1]

HIgh Level Structure

Repository areas

1. Users - contains separate, private areas for each user based on their user ID. [2]
2. Library - access and version controlled artifacts organized by artifact type.
3. System - area reserved for the Komodo application. Default values for preferences, searches, and validation rules are defined here. [2]

    Repository structure

/tko:komodo

/tko:users (currently called /tko:workspace)

/tko:library

/tko:system (currently called /tko:environment)

User Area Detail (two options below)

    Organized by Project option:

Notes

• Users will be able to create and manage projects. [1]
• Each project is organized by artifact type.
• Artifacts of the same type within the same project must have unique names.
• Artifacts of the same type can have the same name if they exist in different projects.
• Overridden preferences and validations will be stored directly under the user.
• Saved searches are stored directly under the user node. [3]
• Projects must have unique names.
• No other nodes besides project nodes can be created directly under the user node.
• Properties can be created on the user node. [4]

Repository Structure

/tko:users

/user_1

/tko:preferences

/tko:validationRules [5]

/tko:searches

/project_1

/dv:dataService

/MyDataService

/MyVdb (reference to /vdb:virtualDatabase/MyVdb)

... (references to other data service artifacts)

/vdb:virtualDatabase

/MyVdb

... (other artifact grouping nodes) [6]

... (other projects)

... (other user areas)

Organized by Artifact option:

Notes

• Projects don't exist.
• /tko:users is currently called /tko:workspace
• Artifact names must be unique within an artifact type. [7]
• Overridden preferences and validations will be stored directly under the user. [8]
• Saved searches are stored directly under the user node.
• No other nodes can be created directly under the user node.
• Properties can be created on the user node.

Repository Structure

/tko:users

/user_1

/tko:preferences

/tko:validationRules

/tko:searches

/dv:dataService

/MyDataService

/MyVdb (reference to /vdb:virtualDatabase/MyVdb)

... (other references to data service artifacts)

/vdb:virtualDatabase

/MyVdb

... (other artifact grouping nodes)

... (other user areas)

Library Area Detail

Notes

• Artifacts are versioned and access controlled.
• Each artifact has a title and description to facilitate them being found in searches.

Repository Structure

/tko:library

/dv:connection

/ConnectionA

... (other connections)

/dv:dataService

/DataServiceA

... (other data services)

/dv:ddlFile

/DdlFileA

... (other DDL files)

/dv:driverFile

/DriverFileA

... (other driver files)

/dv:resourceFile

/ResourceFileA

... (other user resource files)

/dv:udfFile

/UdfFileA

... (other UDF files)

/vdb:declarativeModel

/ModelA

... (other models)

/vdb:virtualDatabase

/VdbA

... (other VDBs)

System Area Detail

Notes

• /tko:system is currently called tko:environment
• Default preferences are stored here.
• Default validation rules are stored here.
• Built-in searches are stored here.
• the Teiid cache is stored here.
• known Teiid servers are stored here.
• hidden from the user

Repository Structure

/tko:system

/tko:preferences

- tko:validateAutomatically = true

- tko:showOdataLinks = true

- tko:tabularDisplayMode = 'LIST'

... (other default preferences)

/tko:validationRules (globally defined validation rules)

/tko:rule1

- tko:severity = 'WARNING'

... (nodes and properties defining the validation rule)

... (other default validation rules)

/tko:searches

/findAllBooleanColumns

/findAllModels

... (other built-in searches)

/tko:servers

/tko:teiidCache

[1] What is the justification for this use-case?

• The need to step away from the catalogue-paradigm was one of the drivers early-on for moving away from Eclipse and a return seems a retrograde step.
• What purpose does the 'project' node server, other than to logically split the artefacts?
• It is possible that nodes can have the same names but it should be entirely possible to simply stop the user from doing this. Inviting the user to add an artefact with a slightly different name seems a much more straight-forward solution;
• The creation of a project would have to be included in dsb, eg. summaries would only show artefacts in specific projects or show all artefacts in all projects, creation of a new artefact would require an extra step of asking the user which project it should be added to unless an open-close-active-project paradigm was implemented;

[2] Is this rename of nodes really necessary?

• Users will not be aware of this structure since the application determines the layout of objects in the user interface. Thus, should a change to the repository be made, a property on each node indicating the display-name perhaps may be a far safer and less disruptive solution;
• Dependencies on tko:workspace include
  • The search framework stores its searches under tko:workspace/searches. These saved-searches are shared to all users and logically makes no sense to store them under tko:users. Moving them though means changes will be required to the core-search, rest-server-side and parts of dsb (not used atm);
  • Each instance of WorkspaceManager is linked to the tko:workspace node since it is in itself a relational object. Should the WorkspaceManager be renamed as well?
  • With the changing of name, irrespective of what to call it, the WorkspaceManager will be effected, especially due to its getFromWorkspace() method. This is widely used in a number of use-cases included import-export;
  • The security framework that determines whether users can read/write nodes in any repository location, ie. RepositoryImpl.provision() relies on the current workspace layout and, although would probably work with the rename, require checking that its tests still pass;
• Dependencies on tko:environment include
  • Teiid servers group - the collection of teiid instance configurations added by any users, including the default running instance that's part of the same jboss;
  • Teiid cache group - the collection of cached teiids which convert the contents of live teiid instances into repository nodes;
  • Validation group - the collection of validation rules used to determine the validity of any artefacts;

[3] The premise of saved-searches is that they are shareable between users and therefore exist at the same level as the user homes rather than hidden inside each user home. After all, storing them in the latter implies that userA would probably end up storing the same search as userB since neither can see the other's.

[4] This would require a change to the security framework since each user node is generated automatically and not owned by the user. Currently, users cannot modify the actual user home nodes.

[5] In the same manner as saved-searches, the validation rules are shareable artefacts and duplication should be discouraged rather than encouraged. More importantly, the rules governing the validity of objects should be consistent across the repository and not subject to be turned on/off at the whim of the user. The implication of such an implementation would mean an artefact looking fine for one user but when added to the library, exported for another user or even deployed could be the artefact is in fact invalid.

[6] Is a logical structuring at the repository-level really required?

• A logical structuring of nodes can be achieved at the application-level using the node types so what purpose would structuring them at the repository-level serve?
• Is the structure mandated? In Designer, the creation of a new project added folders inviting the user to logically separate their artefacts. However, such a structure was not mandated leaving the user free to add artefacts anywhere from the project-level down. If mandated then that would present a number of issues to ensure correct nodes were added to the correct folder. If not mandated then the purpose of doing this in the first place seems questionable.

[7] Difficulty of 'sns'

• The 'sns' property is added to most node types in most cnd files. It appears that this is required but has the implication of indexing same-name-siblings, ie. blah[1], blah[2];
• It might be possible to embrace sns and rather than returning the 'first' node found, return all nodes with a specific name or search for the single node with a specific name AND index. This would then allow same-name nodes at the same level;
• Stopping same-name-siblings can be achieved at the relational or application levels of the stack. For example, the teiid cache only ever allows a single cached-teiid node for each teiid instance. This is done at the relational-level using code-checks.

[8] Certainly, a situation of overriding default choices, ie. preferences, is conceivable but is there a use-case for overriding validation rules on a per-user basis?