jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: Getting "custom" objects from the repository?
Date Sat, 16 Apr 2005 18:56:32 GMT
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.

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

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.

> On 4/16/05, Julien Viet <julien@jboss.com> wrote:
>> invalidate the cache :
>> 
>> - time based invalidation, you say that an entry is valid for 1 minute
>> for instance
>> - notification, you can use JCR observations mechanism to remove entries
>> from the cache
>> 
>> cheers
>> 
>> Daniel Dekany wrote:
>> 
>> >I suppose most applications want to work with objects like mycms.User,
>> >mycms.PageTemplate, myapp.Book, etc., rather than directly with the tree
>> >of items that JCR shows. I don't see what's the intended way of doing
>> >this. With a concrete example: I would like to store page templates in
>> >the repository, which are complex and frequently used objects, so they
>> >shouldn't be recreated from a binary property (or from string string
>> >property, whatever) every time they are read from the repository (that
>> >is, for each page hits). I could use cache in front of JCR that caches
>> >the template objects, but how to ensue that the cache is in sync with
>> >the repository? Of course no hazards and unpredictable delays are
>> >allowed after the repository was modified.
>> >
>> >What's the planned way of doing things like this?
>> >
>> >(I know this is not a Jackrabbit but a JCR question and I apologize for
>> >that, but I didn't found a more suitable public list.)
>> >
>> >
>> >
>> 
>> --
>> Julien Viet
>> JBoss Portal Lead Developer

-- 
Best regards,
 Daniel Dekany


Mime
View raw message