[ http://issues.apache.org/jira/browse/JCR-399?page=all ]
Stefan Guggisberg updated JCR-399:
----------------------------------
Priority: Minor (was: Major)
reducing priority, this is not a major issue.
> DBFileSystem database connections strings stored in database
> ------------------------------------------------------------
>
> Key: JCR-399
> URL: http://issues.apache.org/jira/browse/JCR-399
> Project: Jackrabbit
> Type: Improvement
> Versions: 1.0, 1.0.1, 1.1, 0.9
> Reporter: Miro Walker
> Priority: Minor
>
> Currently the DBFileSystem implementation stores all workspace config in the
> database. This works well, but has one major drawback - the workspace.xml
> files that form part of this config actually contain the database connection
> strings for the workspace. This means that we have database connection
> details actually stored in the database they refer to.
> The result of this is that it is very awkward to restore a backup of the
> database into an environment with a differently named database (for example
> in the case of data centre disaster recovery). We've worked around by
> providing scripts that use the repository API itself to read out the XML,
> modify it and then write it back, but a more direct solution would be much
> better.
> I realise that the reason for storing database connection details in the
> workspace was to allow each workspace to be configured to use a different
> database or filesystem, but in the use case for a DBFileSystem, it seems
> pretty likely that all workspaces will also be in the same database.
> What I suggest is making a configuration available in the repository.xml that
> will force all workspaces to inherit the repository.xml DB connection
> details, ignoring any config in the workspace.xml itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
