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 12:49:14 GMT
Saturday, April 16, 2005, 1:28:01 PM, David Nuescheler wrote:

> hi daniel,
>
>> 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.)
>
> if i understand you correctly i assume that you are talking about
> an object-repository-mapping. this discussion has been started
> quite a number of times, and i think the implementation should be
> pretty straight forward, since jcr puts all the right pieces in to place.
>
> to put this in relation to classical orm (like jdo, hibernate or ejb) 
> which are layers on top of jdbc which run against rdbms,
> i would compare things like this:
>
> 1) jackrabbit plays the role of an rdbms implementation
> 2) jcr plays the role of jdbc

That was exactly what I have afraid of after reading a bit the
specification. I's good that we have a something that is better suited
for certain needs of CMS-es and other Web related stuff than raw
RDBMS-es, but I still feel a lack of vision in the Java world regarding
repositories. JCR replaces this table philosophy with more flexible
trees, it has things like versions, etc, fine, but still it has the
approach that the mapping to objects is not something that the
repository design should take into consideration. Come on, RDBMS-es
become widespread with this philosophy ages before, and we are living in
a different word now. I'm sure the JCR Expert Group has members who are
experts on the CMS field, so they know Zope, more specifically ZODB. I
know that's very different, but still, that's a content repository in
practice, and it has recognized that people want to access content as
objects at some point anyway (I mean, as custom objects like
myapp.Customer), and since it must be done, it is best done inside the
content repository core, because that's the part of the system that
knows about everything happening with the repository, so it's probably
the best place to keep the object mapping cache up to date. I'm not
saying that JCR should do the mapping to objects, I'm just saying that
it would be a killer thing if it let people implement a such object
mapping cache over it that really works and efficient.

> now, this practially means that your question is neither directly a
> jcr

I bet most people wants to access content as "custom objects" at some
point, and ignoring this demand is like designing a house groundwork
technology without considering if it will able to carry the walls people
want to build on it. Hence, the group that works on JCR had to consider
this issue... maybe they have reached the conclusion that they can't
provide solution for this for some reason, something like "Sorry guys,
it's not that thing you have dreamt about yet, you have to wait a few
more years for that, because ...".

> (much like orm is nothing that the jdbc should take care of)

I believe people has got used to the way as RDBMS-es work, since
RDBMS-es are around for a very long time. Then as technology has evolved
people have realized that they want to accesses the data as objects, so
they try to built these ORM things on top of the RDBMS-es, but the
situation is not optimal, since RDBMS-es was not designed for that.

> nor a jackrabbit question (rdbms would provide underlying
> infastructure for orm) but i am sure there is interest in the
> jackrabbit community to tackle this discussion.

I guess this will be something that many CMS (and other) guys want when
they naively(?) first look at JCR, so something should to be said about
this.

> anybody?
>
> regards,
> david

-- 
Best regards,
 Daniel Dekany


Mime
View raw message