I agree completely with you Toby. Actually it is what I did initially. But:
- we tried to minimize impact on core for the backup tool. The updates I propose are the one to minimize its impacts. If we add a import/export, why not add them on all backuped/restored resources? I would be in favor of either adding this method for all resources or to none. For instance to make a resource backuppable, we could implement a Backupable Interface instead of relying on a <Resource>Backup class with two main methods. - If I add a method i the VersionManager, I would have to put some code to escape data consistency checks which is something Stefan wanted to avoid. The underlying issue I think is what should be the place of the backup tool: should be add specific method to backup/restore in core (as thought initially) or should we minimize core modifications? Both ways have advantage and drawbacks. I would go however for a tighter coupling especially since hotbackup will be easier to implement this way. I have checked mysqldump code and they simply make SQL request on each table. So they didn't add any specific code (but at the same time, they are simply dumping mysql tables...). Right now, the code try to be as much separated as possible, but I can quite easily refactor the other way. What are your thoughts on this issue? Nicolas On 8/17/06, Tobias Bocanegra <[EMAIL PROTECTED]> wrote:
> The patches are posted. > > I am waiting for your feedback to perform the last refactoring so we can > start using it. > From Jira Issue: > - Update to VersionManagerImpl and to RepositoryImpl. > In order to restore the NodeVersionHistories, I need to gain access to the > VersionManagerImpl persistence (through a getter) manager. For this, I need > to put the getVersionManager() of RepositoryImpl in public (I couldn't use > the one from SessionImpl since there can be a XAVersionManager and the > cast to VersionManagerImpl doesn't work in this case) this is a wrong asumption, that the version manager stores the versions in a persistence manager. the version manager is intentionally kept abstract, so that an implementation could use another, more efficient way to store the versions. it's not good to access the vesions persistence manager directly. i would prefer adding 3 methods to the version manager: public void exportVersions(OutputStream out) public void exportVersions(ContentHandler handler) public void importVersions(InputStream in, boolean update) that does a systemview like export/import of all version histories, directly below the export-root. doing so, the version export/import is not tied to the persistence anymore. regards, toby -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
-- a+ Nico my blog! http://www.deviant-abstraction.net !!
