jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Newbie questions
Date Sun, 30 Jul 2006 20:06:52 GMT
every persistence manager gets a 'FileSystem' passed in it's context.
this file system is an implementation of the FileSystem interface.
this can be a direct mapping to the java.io stuff, or a database
driven one, or something else.

what the persistence manager does with this filesystem, depends on his
implementation. for example the xml-persistencemgr uses it for storing
the nodestate info in xml-serialized form in the filesystem. where as
the db-based persistence manager, uses it for storing large binary
data (depeding on it's config).

so, depending on the persistence manager and it's config, the
filesystem is used differently. if you want to store 'all' data, item
states, config files, binary data, etc...you can use the db-filesytem
and a db-persistencemanager.

for every workspace, there is a persistence manager configured. for
example, you can define for your workspace 'A' a total filesystem
based persistence manager, and for your workspace 'B' a db-based
persistence manager.

the 'versioning' subsystem uses a 'virtual' workspace for storing the
versions and can therefore be configured like one (well, almost). but
it needs a persistence manager. the versions are like normal states,
they just live in another (virtual) workspace. and when you checkin a
node, it's state is copied in the versions workspace and persisted
with the version persistence manager.

regards, toby

On 7/30/06, James_1 <ponfar99@yahoo.com> wrote:
> Jukka Zitting-3 wrote:
> >
> > The versioning store in Jackrabbit is kind of a system workspace whose
> > contents are shared by all normal workspaces and which can only be
> > seen indirectly as the virtual /jcr:system/jcr:versionStorage subtree
> > of each workspace. Just like normal workspaces allow a FileSystem to
> > be configured for determining where their data is persisted, so does
> > the versioning store.
> >
> > The configured FileSystem instance is passed to the configured
> > PersistenceManager with the idea that it should be used to actually
> > store the persistence files. In effect a PersistenceManager decides
> > how and a FileSystem where the content is persisted. Of course some
> > PersistenceManagers (like the database ones) skip the configured
> > FileSystem and use some other mechanism for storing and retrieving the
> > information.
> >
> Thanks for the response.  I guess I'm still not understanding where
> versioning data is actually persisted.  The PersistenceManager persists the
> versioned NodeStates, but where is the version info persisted?  I don't see
> any kind of version data structure in the NodeState that would get persisted
> (e.g. NodeState.getVersion()).  Or is that info embedded in the id of the
> node, using some kind of naming scheme?
> --
> View this message in context: http://www.nabble.com/Newbie-questions-tf2022590.html#a5565327
> Sent from the Jackrabbit - Users forum at Nabble.com.

-----------------------------------------< 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 >---

View raw message