jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-399) DBFileSystem database connections strings stored in database
Date Fri, 30 Jun 2006 11:08:30 GMT
     [ http://issues.apache.org/jira/browse/JCR-399?page=all ]

Jukka Zitting updated JCR-399:

    Fix Version: 1.1
        Version:     (was: 1.1)

> 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, 0.9
>     Reporter: Miro Walker
>     Priority: Minor
>      Fix For: 1.1

> 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
> 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:
For more information on JIRA, see:

View raw message