jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From greg power <greg.power...@googlemail.com>
Subject Re: How to manage JCR Types with JackRabbit? - a contrast with DDL
Date Sun, 06 Apr 2008 18:04:37 GMT

Hi all,

I'd like to add another use case to Shaun's list:

Use Case 7: Fix Naive Relation

Suppose I find a naive many-to-many relation in some application based on
Hibernate/POJO or EJB. What would I do to fix this? Steps might be:

1) Fix the domain model (maybe add a class or two)
2) Fix the Hibernate mappings/EJB notations (to reflect 1)
3) Write a SQL script to copy the existing tables, drop the old ones, create
& populate replacement tables etc (to reflect 1 & 2)

Being new to jcr I expect to make some howling misjudgments over node
definitions etc and I will want to fix them. From reading the forum it seems
that doing so will be easier said than done and this is giving me the

What seems be to missing is the SQL script element. Brute force it might be,
but it is brutally effective in the real world. I realize there are problems
here: a) jcr is much richer that RDBMS, b) RDBMS has three decades
development under it's belt. I also hear Stefan:

> Q1: Should unregisterNodeType delete instances of that type, and fail if
> the
> deleting any instances breaks a constraint?

"IMO yes. but that's exactly the tricky part. you'd need an exclusive lock
over the entire repository and you'd need find all occurrences in every
workspace  (potentially containing a *lot* of items)..."

What is the way forward with this? Surely either the tried and tested
concept of the brute force script (at owner's risk, of course) should by
default be inherited by jcr, or there should be a shiny, new, elegant
alternative in the jcr pipeline?


View this message in context: http://www.nabble.com/Adding-new-node-types-tp11942091p16527745.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message