Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-599

Allow to inherit workspace configuration from repository level template

    Details

    • Type: New Feature New Feature
    • Status: Patch Available
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 0.9, 1.0, 1.0.1, 1.1
    • Fix Version/s: None
    • Component/s: config
    • Labels:
      None

      Description

      RepositoryConfig file contains section with template for Workspace config. This template is used to create new workspace using jackrabbit internal api, and new workspace configuration file is created based on this template.

      Probably in most scenarios common configuration for all workspaces is used. If you need to make some configuration changes then you have to iterate through each workspace and edit each config file separately.
      It is quit easy task if you are using local file system, but can be hard if other file systems are used (for example using DbFileSystem editing blobs in database is required).

      Our proposal to make some improvement here and allow to inherit workspace configuration by reading it from repository level template. Change made in repository config file will be reflected auomaticallly in all worskpaces then.

      Feature details :

      • if workspace.xml file doesn't exists it can be inherited (read and created in memory from template), no workspace.xml file must be generated,
      • you can still override workspace config by creating workspace.xml file by hand, then this file will be used instead of template,
      • if required additional parameter 'inheritConfig' can be added with default value 'false' to keep current behaviour
        and workspace config inheritance will work only if this parameter is set to 'true'.

      We are working on this feature, and we will contribute patch.

        Activity

        Hide
        Jan Kuzniak added a comment -

        Patch attached. Solution allows to enable this feature and keeps it disabled by default so I see no conflict here. I'm waiting for comments.

        Show
        Jan Kuzniak added a comment - Patch attached. Solution allows to enable this feature and keeps it disabled by default so I see no conflict here. I'm waiting for comments.
        Hide
        Przemo Pakulski added a comment -

        You' re right, all our use cases are administrative tasks.
        By introducing this feature most of these troublesomes tasks can be simplified or avoided at all.

        Creation of workspace is also admistrative task and can be done manually.
        Can you explain what's the reason of introducing workspace config template and createWorkspace method ?
        IMO it was probably also to simplify this task, wasn't it ?

        Show
        Przemo Pakulski added a comment - You' re right, all our use cases are administrative tasks. By introducing this feature most of these troublesomes tasks can be simplified or avoided at all. Creation of workspace is also admistrative task and can be done manually. Can you explain what's the reason of introducing workspace config template and createWorkspace method ? IMO it was probably also to simplify this task, wasn't it ?
        Hide
        Stefan Guggisberg added a comment -

        i am not convinced.

        all your use cases are very special and administrative tasks. it would be trivial to write a simple application that solves your issues.

        Show
        Stefan Guggisberg added a comment - i am not convinced. all your use cases are very special and administrative tasks. it would be trivial to write a simple application that solves your issues.
        Hide
        Przemo Pakulski added a comment -

        Well, I can't agree that repository/workspace configs should be immutable. There is a lot of configuration options available for workspace and many administraction activities which requires change of workspace/repository config to maintain repository.

        See some examples below (from our experience only) :

        • changes of paths required to restore repository from backup on different location and/or on another machine,
        • changes of indexes location to another disk/filesystem becuase of either running out of space or performance reasons,
        • changes of other SearchIndex/PersistanceManager configuration parameters which can impact performance or memory usage,
        • in case of using database PM, changes of db host, db name, username, password or any other DBPM paramaters (including jdbc driver),
        • etc.

        All these changes are quite trivial if you are using LocalFileSystem and single (or a couple of) workspace,
        but becomes painful and errorprone if your repository has many workspaces and/or all configuration files are stored in database using DBFileSystem (our case).
        To change single parameter or path you have to iterate through all workspaces and edit blob content several times ...

        Naturally not all changes are possible and you should be aware what are you doing exactly.
        As I mentioned before we can add additional parameter 'inheritConfig' with default value set to 'false'.
        Without setting explicitly this parameter to 'true' everything wilk work exactly as before, so this change will be transparent and backward compatible.

        Show
        Przemo Pakulski added a comment - Well, I can't agree that repository/workspace configs should be immutable. There is a lot of configuration options available for workspace and many administraction activities which requires change of workspace/repository config to maintain repository. See some examples below (from our experience only) : changes of paths required to restore repository from backup on different location and/or on another machine, changes of indexes location to another disk/filesystem becuase of either running out of space or performance reasons, changes of other SearchIndex/PersistanceManager configuration parameters which can impact performance or memory usage, in case of using database PM, changes of db host, db name, username, password or any other DBPM paramaters (including jdbc driver), etc. All these changes are quite trivial if you are using LocalFileSystem and single (or a couple of) workspace, but becomes painful and errorprone if your repository has many workspaces and/or all configuration files are stored in database using DBFileSystem (our case). To change single parameter or path you have to iterate through all workspaces and edit blob content several times ... Naturally not all changes are possible and you should be aware what are you doing exactly. As I mentioned before we can add additional parameter 'inheritConfig' with default value set to 'false'. Without setting explicitly this parameter to 'true' everything wilk work exactly as before, so this change will be transparent and backward compatible.
        Hide
        Stefan Guggisberg added a comment -

        > [...]
        > Probably in most scenarios common configuration for all workspaces is used. If you need to make some configuration changes then you have to iterate through each workspace and edit each config file separately.
        > It is quit easy task if you are using local file system, but can be hard if other file systems are used (for example using DbFileSystem editing blobs in database is required).

        i don't see your point. the repository & workspace configs are meant to be immutable once they're in use.
        editing the configs while there is existing content is dangerous and almost certainly leads to data
        inconsistencies. e.g. changing the 'externalBlobs' parameter leads to corrupt binary properties.

        i am not in favor of the proposed feature.

        Show
        Stefan Guggisberg added a comment - > [...] > Probably in most scenarios common configuration for all workspaces is used. If you need to make some configuration changes then you have to iterate through each workspace and edit each config file separately. > It is quit easy task if you are using local file system, but can be hard if other file systems are used (for example using DbFileSystem editing blobs in database is required). i don't see your point. the repository & workspace configs are meant to be immutable once they're in use. editing the configs while there is existing content is dangerous and almost certainly leads to data inconsistencies. e.g. changing the 'externalBlobs' parameter leads to corrupt binary properties. i am not in favor of the proposed feature.

          People

          • Assignee:
            Unassigned
            Reporter:
            Przemo Pakulski
          • Votes:
            5 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development