Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <d8ffccc20803171615t6589be62g4dd843be86794b36@mail.gmail.com>
Date: Tue, 18 Mar 2008 00:15:01 +0100
From: "Greg Klebus" <greg@klebus.com>
To: users@jackrabbit.apache.org
Subject: Re: Storing "traditional entites" in the repository
In-Reply-To: <-448053240940054243@unknownmsgid>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <-448053240940054243@unknownmsgid>

Hi Leander,

Interesting question indeed. I'm not an expert in JCR content
modeling, but I certainly understand the value of the standard, and
I've also been through some J2EE+DB types of projects, where JCR would
address some fundamental problems with managing content. Here are my 2
cents:

On Thu, Mar 13, 2008 at 4:35 PM, Leander Reimer
<leander.reimer@vva-networks.de> wrote:
>  I am currently evaluating Jackrabbit as a content repository for an asset
>  management system. Fine so far.

Good choice indeed. So far so good, asset is a "real content."

>  Now I also need to store other objects which I would not really classify as
>  content, like company or user "entities" with the usual dependencies, which
>  I would usually persist using ORM tools like Hibernate or JPA.

Why would you not treat them as content? This is a very interesting
question, why this types of entities would be treated as something
else than content. I think there are some reasons (some practical,
some because of "traditional" approach), why one may treat them
differently.

Could you think of benefits of storing these "other objects" not in the JCR?

>  Being new to the topic of content modelling I was wondering whether it is a
>  good idea to store these objects also in the JCR repository? Or should I
>  keep the 2 approaches separated.

I would recommend storing these 'objects' in JCR. And I think they are
perfect examples of content, too. I know it might be a bit
content-orthodox, but once you start thinking about everything as
content in the first place, and only rule out things not to be stored
in a content repository as an exception, the unified access to all you
need to manage (content) makes things so much more natural and easier.

>From the practical perspective, it might be beneficial to consider
managing some pieces of content (like user or company information in
your case) elsewhere. Like:

- You already have, or need, directory services (LDAP & the like) for
user & organizations data
- You already do, or need to, manage these special pieces of
information somewhere (because of other systems, etc)
- You have other considerations that make JCR not the first choice

In situations like this I'd look for a way to integrate this external
content into JCR (integration module) to make accessing the
information from JCR applications easier.

>  Was JCR/Jackrabbit ever meant to store "traditional entities" or should it
>  only be used to store "real content" such as images, web pages, ...?

Yes.

I believe that the JCR has been created to a) be able to manage as
broad a scope of information (content) as possible, and to b) provide
developers / applications using the JCR with a rich set of content
services (think RDBMS/Filesystem/and more) to make working with the
unified content easier.

>  Thanks for any advice and recommendations.

Are there other opinions here?

Cheers
Greg

-- 
-- Greg Klebus | http://day.com | http://dev.day.com
-- Best open-source JCR repository: http://jacrkabbit.apache.org