hi phil, i am sorry for not reading you initial post carefully enough. i think splitting the large xml file into various nt:resources may be a good solution, another way would be to introduce something like an xml-fragement node that just hosts an xml fragment in a single string or binary property and could be placed into any "standard" xml structure at the point where the desired granularity is reached.
i would assume that since your application probably wants to define how the xml is broken into pieces it may still require you to make those decisions in the application anyway. does that make sense? regards, david On 10/2/07, woolly <[EMAIL PROTECTED]> wrote: > > Thanks for your reply, > > If I use a document view import (via session.importXML()) then the document > is exploded underneath the node to which I import and the size of the > repository increases enormously (an 8Mb file takes up 120Mb on disk or > something silly!) > That's why I've had to store some parts of the document as nt:resource so > that I can get my full document in. > Unfortunately, though, I still need CMS style functionality on some bits of > the xml in the nt:resource. I was just wondering if there's a "standard" way > of doing this, or if anyone had any good ideas...? > > > > David Nuescheler-3 wrote: > > > > Hi Phil, > > > > I think you may be looking for what's called an XML > > DocumentView import. > > > > This allows you to deal with your XML document on an > > XML-element/attribute level, when it comes to content > > repository features such as versioning, locking or query. > > > > regards, > > david > > > > On 10/2/07, woolly <[EMAIL PROTECTED]> wrote: > >> > >> Hi all, > >> > >> I have recently had a problem where I was trying to import a large xml > >> document into the jackrabbit repository. The repository expanded hugely > >> during import. I solved this problem by having some elements of the xml > >> stored as an nt:resource node (as jcr:data with an xml mimetype). > >> > >> Now I've got the problem that I want repository features such as > >> versioning > >> and referencing to apply to some parts of the xml that is stored in the > >> nt:resource. Does anyone have any ideas on the best way to implement > >> this? > >> I'm thinking about taking the xml chunk I want to version out of the > >> nt:resource and then storing it somewhere else. But then, what's the best > >> way of making the link between the nt:resource xml and the new "exploded" > >> xml? > >> > >> Is there a better way to allow repository features to apply to parts of > >> xml > >> stored in an nt:resource? > >> > >> Thanks for any help, > >> > >> Phil. > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/CMS-Functionality-In-An-nt%3Aresource---tf4554191.html#a12996511 > >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/CMS-Functionality-In-An-nt%3Aresource---tf4554191.html#a12996738 > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >
