jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakesh Vidyadharan <rak...@sptci.com>
Subject Re: Repository storage structure change, exportSystemView and importXML
Date Fri, 12 Feb 2010 15:15:54 GMT
Right, if you have multiple root level nodes, you will need to do the export for each (assuming
that is even an option if you have references).  The other option may be to try document view
export from /, which I believe does not include jcr:system.

Rakesh

On 12 Feb 2010, at 07:36, Fabián Mandelbaum wrote:

> AFAIK, there's no way to filter out nodes using exportSystemView,
> other than making several exports from the "correct" paths to avoid
> exporting the nodes you don't want...
> 
> On Fri, Feb 12, 2010 at 10:16 AM, Rakesh Vidyadharan <rakesh@sptci.com> wrote:
>> I think the issue may be that the export also includes the protected /jcr:system
node.  See if you can export just your /xxx nodes...
>> 
>> Rakesh
>> 
>> On 12 Feb 2010, at 06:21, Fabián Mandelbaum wrote:
>> 
>>> Hello,
>>> 
>>> I'm using JR 1.4. While developing my application there's been changes
>>> to some nodes (mix:lockable added), and there were some stored nodes
>>> that are not needed anymore (for example, nt:file nodes stored on /).
>>> I have no custom nodes defined, am only using nt:file , nt:folder and
>>> nt:unstructured for all the rest.
>>> 
>>> I need to migrate an old repository to the new storage schema. This
>>> requirement may hold true for future versions of my own system (ex: V3
>>> vs. V2), as the system evolves. The strategy I'm currently trying (if
>>> you know of a better one, please let me know), is the following:
>>> 
>>> 1) exportSystemView of the whole repo: session.exportSystemView("/",
>>> os, false, false);
>>> 2) perform an XSLT transformation (for example with xsltproc) and a
>>> custom XSL that will remove/add/modify nodes as needed, according to
>>> the changes between old and new repo storage structure: xsltproc
>>> migrate.xsl repoExport.xml > newRepo.xml
>>> 3) Import newRepo.xml into the existing old repo:
>>> session.importXML("/", is,
>>> ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
>>> 
>>> Step nbr 3) is throwing an exception stating that protected nodes
>>> cannot be overwritten (which sounds fine from a data integrity point
>>> of view, but throws this strategy out of the window).
>>> 
>>> I guess that if instead of using an existing repo for step 3, I create
>>> a new empty one, and then try to import over it, things won't change
>>> much because the new empty repo will already have protected  nodes
>>> (those under /jcr:system, for example).
>>> 
>>> So, what can I do to 'fix' this? Start the import 'somewhere else'
>>> instead of at "/" (how would I eliminate nodes that are stored there
>>> and I don't need anymore)? Forget about this strategy and write a
>>> small program that makes the modifications "by hand" (as oposed to an
>>> automated import) every time I need to migrate an old repo storage
>>> structure?
>>> 
>>> Am I using the right APIs? Is importXML the counterpart to exportSystemView?
>>> 
>>> Too many questions, I know... but I'm kinda stuck.
>>> 
>>> Thanks in advance for your answers.
>>> 
>>> --
>>> Fabián Mandelbaum
>>> IS Engineer
>> 
>> Rakesh Vidyadharan
>> President & CEO
>> Sans Pareil Technologies, Inc.
>> http://sptci.com/
>> 
>> 
>> | 100 W. Chestnut, Suite 1305 | Chicago, IL 60610-3296 USA |
>> | Ph: +1 (312) 212 3933 | Mobile: +1 (312) 315-1596 (US), +91  949 611 0873 (IN)
| Fax: +1 (312) 276-4410 | E-mail: rakesh@sptci.com
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> Fabián Mandelbaum
> IS Engineer

Rakesh Vidyadharan
President & CEO
Sans Pareil Technologies, Inc.
http://sptci.com/


| 100 W. Chestnut, Suite 1305 | Chicago, IL 60610-3296 USA |
| Ph: +1 (312) 212 3933 | Mobile: +1 (312) 315-1596 (US), +91  949 611 0873 (IN) | Fax: +1
(312) 276-4410 | E-mail: rakesh@sptci.com





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message