On Mon, Mar 30, 2009 at 5:52 PM, Connor, Brett (LNG-TWY) <[email protected]> wrote: > I've been exploring putting referential integrity on the Jackrabbit > tables for the BPM. > > The background to this is that we regularly get QA reporting problems in > testing that boil down to some form of NoSuchItemStateException. Many of > these we eventually trace back to manual process errors copying > databases around, redeploying servers etc. However often we can't prove > anything about how it occurred. > > I've added a FK constraint from one of our tables to the BPM BUNDLE > table, but AFAICT everything else is stored as binary data. Has anyone
just some background information to (hopefully) help you better understand jackrabbit's current design: the abstraction of jackrabbit's storage layer basically provides a way of storing/retrieving an opaque object by key (much like a persistent hashmap). relational databases were obviously not the first choice for implementing the storage layer since they're somehow overqualified for the job. something like a berkeley db seemed a better fit. when more and more people asked for a rdbms-based storage layer we provided a 'simple' implementation which stores the internal node state represantations as opaque objects in a 2-column table. we've deliberately chosen to not use a fully normalized database schema for performance reasons since that would require *a lot more* db write operations without any significant gain. cheers stefan > explored or thought about the possibility of adding more fundamental > integrity checks here? I know there are consistency check config options > for JackRabbit startup, I was hoping to achieve something to flag errors > instantly, especially to catch the manual errors. > > Regards > Brett > > LexisNexis is a trading name of REED ELSEVIER (UK) LIMITED - Registered > office - 1-3 STRAND, LONDON WC2N 5JR > Registered in England - Company No. 02746621 > >
