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 collywobbles. 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? regards gregor -- 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.
