[ http://issues.apache.org/jira/browse/JCR-399?page=comments#action_12375146 ]
Marcin Cenkier commented on JCR-399: ------------------------------------ >> Currently the DBFileSystem implementation stores all workspace >> config in the database. > > not quite correct. a DbFileSystem doesn't store anything > particularly, it depends on your specific configuration. to have the recoverable repository, we should use transactions, and store everything that is not self recovering (eg. indexes) inside 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. > > again, that's subject to your specific configuration. you could store > workspace configuration in the local file system or in another > database for that matter. still, to restore a database in a different location, we'd have to parse those 'workspace.xml's and substitute the connect string to allow the repository to work at all. > note that storing everything (i.e. configuration and repository > state) in the same db is a very special use case/setup that i would > not recommend in general. I would recommend to have ONE configuration file, and not 1 + number of workspaces configuration files. This makes sense (if any) only for file system PM,as it uses relative paths, and such repository can be easily moved to a new location. >> 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. > > -1, that would mean mixing different and unrelated level of > abstractions. repositry.xml doesn't know anything about db > connections and doesn't need to. db connection details are the > business of the specialized db-based pm's and file systems. really? check the repository.xml - this is the only place where you can configure the connect strings to the database (and it should be the only place, where such configuration occurs). it is the workspace.xml, that is (in my opinion) obsolete, as it only duplicates the configuration from repository.xml, and is created during runtime by Jackrabbit itself. > 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
