Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of benpickering@gmail.com
 designates 64.233.184.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=L13Gd6Up7bfEfuzfPIpZwQ5uDwmySTFMr+3GM6mGNEAGKkpzBICGdM3kbFi0RWbPNzD9rNRmtPXSRmjFc21IHd21tEz22ancHcr2Xoc3wt8XJeUlkysLfvuYd0o7Y5j0SwvUy6MH6blGz3abTR19hK0bN3GSQvgkwreH712aW/0=
Message-ID: <debf8b1a0504161949efad531@mail.gmail.com>
Date: Sun, 17 Apr 2005 03:49:00 +0100
From: Ben Pickering <benpickering@gmail.com>
Reply-To: Ben Pickering <benpickering@gmail.com>
To: jackrabbit-dev@incubator.apache.org, Daniel Dekany <ddekany@freemail.hu>
Subject: Re: Getting "custom" objects from the repository?
In-Reply-To: <826865421.20050416205632@freemail.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <181174235.20050416061620@freemail.hu>
 <426119F3.4060809@jboss.com>
	 <debf8b1a0504161027fc99159@mail.gmail.com>
	 <826865421.20050416205632@freemail.hu>

On 4/16/05, Daniel Dekany <ddekany@freemail.hu> wrote:
> Saturday, April 16, 2005, 7:27:29 PM, Ben Pickering wrote:
>=20
> > I think some use cases would be useful here, to assess how much of a
> > problem / not-a-problem this is, and whether this is an area that is
> > so application-specific that a pre-specified "framework" is
> > inappropriate.
>=20
> I really don't understand this... are we living on different planets, or
> I fundamentally misunderstand something? :-/ Of course you want to
> access entities as myapp.Customer Java objects and mycms.Template Java
> objects and like in your applications and in your CMS and in your
> whatever web application framework, and not as javax.jcr.Node-s and
> javax.jcr.Properties. Not only because that's more convenient, but
> primarily because you just can't use the "serialized" form of an object
> directly. And of course you need "ACIDity" if you are working on server
> side applications, with a repository that are potentially used (and
> worst, modified) by multiple clients concurrently, so an out-of-sync
> cache that spoils it is not good. And not caching is not an option for
> more heavyweight entities like a script (that is pre-parsed from text to
> a mycms.Script object). But anyway, see my response to Julien Viet's
> mail.

I think that when you say that "Of course you want to access entities
as myapp.Customer.." the JCR folks might disagree -- there's
absolutely no reason why the Nodes and Properties are not sufficient.=20
This was my original question: is it or is it not the case that an
approach to higher-level objects is needed?

Any changes made via these higher-level objects, being based on the
JCR API, can be *nothing but* ACID -- how would a higher-level object
bypass this fundamental characteristic, cached or otherwise?

> > On the "no" side it's worth noting that building higher-level
> > abstractions on a JCR-compliant repository will be a lot easier than
> > on top of an RDBMS, thanks to the mechanisms that Julien mentions.
> >
> > But on the "yes" side, I would certainly prefer to deal with
> > higher-level objects, and I would also appreciate an ecosystem of
> > pre-written ones to help me.  Does this imply that a framework is
> > needed?
>=20
> I would be happily build a such framework, but I don't see how... JCR
> nodes doesn't even have some kind of automatically maintained
> last-modified property that I could use for quickly checking if the
> object in the cache is outdated or not. It is almost everything that is
> needed for the happiness. Seems to me such a low hanging fruit...

Doesn't JCR have modification listeners that could notify a cache if
the data underlying an object changed?  It's this type of thing that
could be in the framework:
- base an object on Items (data and structure) in the repository=20
- register listeners to invalidate the objects if these Items change
- interfaces to let client code know this has happened

It's entirely layered on top of JCR -- there's no way the expert group
is going to allow anything like this into the spec (and I'd agree with
that).  I just wonder if there's any common ground that can be
exploited.  For instance, I'd expect Day's CRX implementation to
include a "User" object; I'm interested to what extent their chosen
approach for this might constitue a pattern that can be (informally?)
standardised.
=20
> Node n =3D (Node) session.getItem("/foo/theTemplate");
> cacheEntry =3D cache.get("/foo/theTemplate");
> if (!n.getStamp().equals(cacheEntry.getStamp())) {
>     The cached object is outdated, so let's recreate using the
>     current value of the insertsomethinghere property.
> } else {
>     return cacheEntry.getObject()
> }
> > I started to talk about this on jackrabbit-dev previously
> > (
> > http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg0063=
9.html
> > )
> > where I talked about a "TableAtom" (in JCR parlance this would be a
> > TableProperty, I guess)  that wrapped a Property and added a
> > high-level API to get/set table entries in a table encoded as a
> > string.  I didn't get a lot of interest in that thread :) but I think
> > it's a valid idea, and one that has caused me *real-life pain* in the
> > past.
> >
> > So: an issue or not an issue?
>=20
> Well, I'm new to JCR and not a big "expert" anyway, but I still risk
> saying that it *is* an issue.

OK, well you and me both :)
=20
--=20
Cheers,
Ben