jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dan" <danz8...@hotmail.com>
Subject RE: What is the better approach for publishing contents?
Date Fri, 11 Aug 2006 18:38:27 GMT
Hi Marcel,
Thank you very much for your response. 

Another question is, if I use RDBMS (db2, e.g.) for PersistenceManager and
FileSystemManager, would the Lucene indexes (workspace and versionstorage)
be located on the file system? Or within the database?

Thanks & Best Regards,
Dan

> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: August 11, 2006 1:25 PM
> To: users@jackrabbit.apache.org
> Subject: Re: What is the better approach for publishing contents?
> 
> Hi Dan,
> 
> The first approach is in my opinion the one to prefer. There are a
> couple of reasons why:
> 
> - the hierarchy of the version storage is different from the
> workspace. Searching for nodes that are under a specific path is quite
> complicated just using the version storage.
> 
> - each query will have to include a 'live' tag clause to filter out
> matches that are not of interest.
> 
> - some repository implementations might not support searches on the
> version storage
> 
> - searching just the workspace will probably be less expensive because
> it contains less content.
> 
> - There is an easy way to keep the 'live' workspace up-to-date:
> register an event listener on the version storage and update whenever
> a live tag is created, moved or deleted.
> 
> regards
>   marcel
> 
> dan wrote:
> > Hi All,
> >
> > I'm quite new to Jackrabbit and am at the point of deciding how the
> > versioned contents should be published / accessed in my application.
> Could
> > anyone advise / comment on the question below? Thanks in advance.
> >
> >
> >
> > Application background:
> >
> > All contents are versioned, and labelled with tags like "Live",
> "Pending",
> > "Draft" etc. When a new version is published, I would check it in and
> label
> > it as "Live". When new revision is being created, I would do a quick
> > check-out/check-in, to create a new "Draft" version. Then check it out
> for
> > modification. This is because the business requirement asks that the
> "Live"
> > version should be always available until a newer version is published.
> >
> > Web users only see "Live" contents and they need to be able to search
> "Live"
> > contents by specifying multiple metadata values.
> >
> > I have been considering two options:
> >
> > 1.	Create a "Live" Workspace which "clones" all "Live" versions of
> > content nodes in the authoring workspace. Content searches are always
> > performed against the "Live" workspace.
> > 2.	Use the Version labels and all content access and searches are
> > performed against the version storage, by getting the "Live" version
> from
> > the version history.
> >
> >
> >
> > The first option seems easier to implement and the second one is also
> > attempting because it saves storage space as well as the extra work of
> > maintaining a "mirroring" workspace.
> >
> > For the second option, I'm especially interested in learning from you
> gurus
> > about its impact on searching for contents, because in that case, all
> "live"
> > contents would be the version storage. And any search must be performed
> > within either nt:Version or nt:VersionHistory.
> >
> >
> >
> > Which is a better approach according to your experience?
> >
> >
> >
> > Best Regards,
> >
> > Dan
> >
> >


Mime
View raw message