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
