jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas " <nto...@gmail.com>
Subject Re: Adding a method to PropInfos
Date Thu, 17 Aug 2006 13:34:53 GMT
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 <tobias.bocanegra@day.com> 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
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> 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 !!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message