You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Vidar Ramdal <vi...@idium.no> on 2008/04/14 12:37:45 UTC
Importing and exporting
Hi all;
I'm trying to migrate data from one repository to another.
So I export a top-level folder (called "/admin") to an XML file, using
Session.exportSystemView. This results in an XML file which looks OK,
and where all nt:files and nt:folders are represented as binary data.
I suppose this is normal.
Then I import into the other repository, using Session.importXML. I
get no error messages, and the hierarchy is reflected in the receiving
repository.
However, files and folders do not seem to be restored properly. I have
an HTML file in the /admin folder, and when inspecting it after
import, it is rendered as a stream of bytes - not as the actual text,
as I would have expected.
Is there a bug in either exportSystemView or importXML when it comes
to files? Or am I doing something wrong in the migration?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Importing and exporting
Posted by Joshna Reddy <jo...@gmail.com>.
Hi Ivan
For repository Migration i wanted to use jcr-backup tool which you were
mentioning in many mail threads.I want to suggest JCR-BackUP tool for
customers using Mirage
https://mirage.dev.java.net.<https://mirage.dev.java.net/>
I didnt find any help or documentation on source forge site.
Does this tool support jackrabbit 1.4 repositories and large binary data.
If i am using DBPersistence Manager to store my data .Does the backup and
migration take care of it .I mean does the backup and import still works
with jcr-backup tool.
It will be helpful for me, if you can answer my doubts
Thanks
K.Joshna
On Mon, Apr 14, 2008 at 7:39 PM, Ivan Latysh <iv...@gmail.com> wrote:
> Vidar Ramdal wrote:
>
> I'm trying to migrate data from one repository to another.
>> So I export a top-level folder (called "/admin") to an XML file, using
>> Session.exportSystemView. This results in an XML file which looks OK,
>> and where all nt:files and nt:folders are represented as binary data.
>> I suppose this is normal.
>>
> Have a look at:
> https://sourceforge.net/projects/jcr-backup
>
> --
> Ivan Latysh
> IvanLatysh@gmail.com
>
Re: Importing and exporting
Posted by Ivan Latysh <iv...@gmail.com>.
Vidar Ramdal wrote:
> I'm trying to migrate data from one repository to another.
> So I export a top-level folder (called "/admin") to an XML file, using
> Session.exportSystemView. This results in an XML file which looks OK,
> and where all nt:files and nt:folders are represented as binary data.
> I suppose this is normal.
Have a look at:
https://sourceforge.net/projects/jcr-backup
--
Ivan Latysh
IvanLatysh@gmail.com
Re: Importing and exporting
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 14, 2008 at 3:15 PM, Vidar Ramdal <vi...@idium.no> wrote:
> On Mon, Apr 14, 2008 at 2:41 PM, Conoly, Brett
> <Br...@digitalinsight.com> wrote:
> > This is only a guess but the jcr:content node has a mimetype property,
> > are you setting that correctly when you first put the new nodes into the
> > repository? There are actually a few ways to automate this using
> > already written code. There's JMimeMagic which reads the bytes but
> > can't really tell the difference in different text files, i.e. text/html
> > -> text/plain. There's also sun's MimeTable which seems to be based on
> > the extension and will be able to interpret different types of text
> > based files. Again this is just a guess but it may work.
>
>
> Thanks for your suggestion, but the MIME type is correct in the
> exporting repository, and is also set correctly in the importing
> repository.
>
> I see the problem now: The jcr:data property is a Binary in the
> exporting repository, but a String in the importing. How could this
> have happened?
And, BTW, the value of the jcr:data property is garbled (that is, a
Base64-encoded String).
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Importing and exporting
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 14, 2008 at 3:35 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
>
> On Mon, Apr 14, 2008 at 4:15 PM, Vidar Ramdal <vi...@idium.no> wrote:
> > I see the problem now: The jcr:data property is a Binary in the
> > exporting repository, but a String in the importing. How could this
> > have happened?
>
> That typically happens if you use the document view export on an
> unstructured node. In that case the import has no way of determining
> whether the imported property is a string or a binary.
>
> Are you sure you're using system view export?
Well, I *was* sure, until you made me check again :)
You were perfectly right, I was using document view export. With
system view, everything works smoothly.
Thanks a lot!
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Importing and exporting
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Apr 14, 2008 at 4:15 PM, Vidar Ramdal <vi...@idium.no> wrote:
> I see the problem now: The jcr:data property is a Binary in the
> exporting repository, but a String in the importing. How could this
> have happened?
That typically happens if you use the document view export on an
unstructured node. In that case the import has no way of determining
whether the imported property is a string or a binary.
Are you sure you're using system view export?
BR,
Jukka Zitting
Re: Importing and exporting
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 14, 2008 at 2:41 PM, Conoly, Brett
<Br...@digitalinsight.com> wrote:
> This is only a guess but the jcr:content node has a mimetype property,
> are you setting that correctly when you first put the new nodes into the
> repository? There are actually a few ways to automate this using
> already written code. There's JMimeMagic which reads the bytes but
> can't really tell the difference in different text files, i.e. text/html
> -> text/plain. There's also sun's MimeTable which seems to be based on
> the extension and will be able to interpret different types of text
> based files. Again this is just a guess but it may work.
Thanks for your suggestion, but the MIME type is correct in the
exporting repository, and is also set correctly in the importing
repository.
I see the problem now: The jcr:data property is a Binary in the
exporting repository, but a String in the importing. How could this
have happened?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
RE: Importing and exporting
Posted by "Conoly, Brett" <Br...@digitalinsight.com>.
This is only a guess but the jcr:content node has a mimetype property,
are you setting that correctly when you first put the new nodes into the
repository? There are actually a few ways to automate this using
already written code. There's JMimeMagic which reads the bytes but
can't really tell the difference in different text files, i.e. text/html
-> text/plain. There's also sun's MimeTable which seems to be based on
the extension and will be able to interpret different types of text
based files. Again this is just a guess but it may work.
Hope this helps,
Brett
-----Original Message-----
From: Vidar Ramdal [mailto:vidar@idium.no]
Sent: Monday, April 14, 2008 7:02 AM
To: users@jackrabbit.apache.org
Subject: Re: Importing and exporting
On Mon, Apr 14, 2008 at 12:37 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Hi all;
>
> I'm trying to migrate data from one repository to another.
> So I export a top-level folder (called "/admin") to an XML file,
using
> Session.exportSystemView. This results in an XML file which looks OK,
> and where all nt:files and nt:folders are represented as binary data.
> I suppose this is normal.
>
> Then I import into the other repository, using Session.importXML. I
> get no error messages, and the hierarchy is reflected in the
receiving
> repository.
>
> However, files and folders do not seem to be restored properly. I
have
> an HTML file in the /admin folder, and when inspecting it after
> import, it is rendered as a stream of bytes - not as the actual text,
> as I would have expected.
The bytes that are dumped are of course the Base64 representation of
the file contents. So it seems that contents of nt:file are not
decoded when importXMLing. This makes sense (kindof).
So, if this is not a bug, one question remains: How do I export and
import a subtree including binary files?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: Importing and exporting
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 14, 2008 at 12:37 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Hi all;
>
> I'm trying to migrate data from one repository to another.
> So I export a top-level folder (called "/admin") to an XML file, using
> Session.exportSystemView. This results in an XML file which looks OK,
> and where all nt:files and nt:folders are represented as binary data.
> I suppose this is normal.
>
> Then I import into the other repository, using Session.importXML. I
> get no error messages, and the hierarchy is reflected in the receiving
> repository.
>
> However, files and folders do not seem to be restored properly. I have
> an HTML file in the /admin folder, and when inspecting it after
> import, it is rendered as a stream of bytes - not as the actual text,
> as I would have expected.
The bytes that are dumped are of course the Base64 representation of
the file contents. So it seems that contents of nt:file are not
decoded when importXMLing. This makes sense (kindof).
So, if this is not a bug, one question remains: How do I export and
import a subtree including binary files?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway