jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Pickering <benpicker...@gmail.com>
Subject Re: Getting "custom" objects from the repository?
Date Sun, 17 Apr 2005 02:49:00 GMT
On 4/16/05, Daniel Dekany <ddekany@freemail.hu> wrote:
> Saturday, April 16, 2005, 7:27:29 PM, Ben Pickering wrote:
> > 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.
> 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. 
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?
> 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 
- 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?)
> Node n = (Node) session.getItem("/foo/theTemplate");
> cacheEntry = 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/msg00639.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?
> 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 :)

View raw message