You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Fabián Mandelbaum <fm...@gmail.com> on 2010/02/12 13:21:26 UTC
Repository storage structure change, exportSystemView and importXML
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
Re: Repository storage structure change, exportSystemView and
importXML
Posted by Fabián Mandelbaum <fm...@gmail.com>.
Hello,
Document View also includes the jcr:system tree. I've added this:
<xsl:template match="sv:node[@sv:name='jcr:system']">
<xsl:message>Skipped /jcr:system subtree ...</xsl:message>
</xsl:template>
to the XSL processing the migration (input is a system view export),
and got other errors now.
I guess I'll just try to build a small program that will connect to
the repo, perform the changes needed, disconnect from the repo, done.
This 'generic' approach to repo manipulation through export XML,
manipulate XML, import back, is giving me lots of headaches.
Thanks for your help anyway. Have a nice weekend.
On Fri, Feb 12, 2010 at 12:15 PM, Rakesh Vidyadharan <ra...@sptci.com> wrote:
> 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 <ra...@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
>
>
>
>
>
--
Fabián Mandelbaum
IS Engineer
Re: Repository storage structure change, exportSystemView and importXML
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
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 <ra...@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
Re: Repository storage structure change, exportSystemView and
importXML
Posted by Fabián Mandelbaum <fm...@gmail.com>.
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 <ra...@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
Re: Repository storage structure change, exportSystemView and importXML
Posted by Rakesh Vidyadharan <ra...@sptci.com>.
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