Export/Import problem

Topics: Developer Forum
Oct 10, 2008 at 11:58 PM
Hi

I'm having a couple of issues when trying to export from n2WebA to n2WebB.

The first is a problem with the datetime format: The servers have different regional settings. n2WebA exports the datetime as "dd/MM/yyyy" and n2WebB tries to import it as "MM/dd/yyyy". I can get around this by performing a regex find/replace on the xml document, but it might be worth looking into.

Second:
I have some items defined with EditableChildren. It seems that the import/export process correctly copies these children across to the other server - I can see them in the Navigation Tree (heirarchy looks fine), but they don't seem to be associated with the Parent anymore.
Here is the code for one of the properties:

[

EditableChildren("Images", "", 230, ContainerName = ImageGallery.GalleryImages)]
public virtual IList<GalleryItem> Images
{
   get
   {
       return new ItemList<GalleryItem>(Children, new TypeFilter(typeof(GalleryItem)));
   }
}

Any ideas?

Thanks
Matthew

 

Coordinator
Oct 11, 2008 at 7:51 PM
Looks like the zonename property is lost when exporting (a bug). While you're fixing the xml file manually you can try setting zoneName="Images".
Oct 12, 2008 at 3:10 AM
Thanks - Is there a way to hook into the export event? I will be using the Export/Import function alot (Development=>Production), so I'd prefer to automate it if I can        
Coordinator
Oct 12, 2008 at 10:27 AM
Not many events at the moment. Most of the methods are virtual so you could inherit the Importer or Exporter and override various methods. Then you can configure your class as a service. An alternative would be creating the events you need and send the changes as a patch.
Oct 14, 2008 at 1:18 PM
Hi

It was a problem with the zonename property. It seems that because I didn't specify a ZoneName in the EditableChildren attribute, it was inserting NULL into the the zonename field of the remote database. I simply supplied the attribute with a ZoneName of "Images" and now everything is working fine.

If anyone else is having problems exporting and importing between servers with different culture/regional settings, here are the modifications I made to the N2 source:

In ElementWriter, I changed the DateTime.ToString line in the WriteAttribute methods to:
   
    WriteAttribute(attributeName, value.ToUniversalTime().ToString(System.Globalization.CultureInfo.InvariantCulture)); // Two of these

In ItemXmlReader, I updated the ReadDefaultAttributes method to include the InvariantCulture when parsing the datetime value:

    DateTime.Parse(attributes["updated"], System.Globalization.CultureInfo.InvariantCulture).ToLocalTime(); // Two of these

I also did the same in the XmlReader base class (ToNullableDateTime method).

Everything seems to be working fine now - The datetime values are being correctly exported/imported and converted.

Coordinator
Oct 14, 2008 at 9:45 PM
Sweet! I've applied your fix. Shout out if you se anything strange.

http://code.google.com/p/n2cms/source/detail?r=460

Dec 2, 2008 at 1:38 PM
On a related note: the same problem with date format still remains for DateTimeDetail.

Here is the patch (along with another small fix):

<file name="20081202-n2-export-fix_date_details.patch">
Index: DetailXmlWriter.cs
===================================================================
--- DetailXmlWriter.cs (revision 501)
+++ DetailXmlWriter.cs (working copy)
@@ -31,7 +31,7 @@
  {
  detailElement.WriteAttribute("name", detail.Name);
  detailElement.WriteAttribute("typeName", SerializationUtility.GetTypeAndAssemblyName(detail.ValueType));
-
+
  if (detail.ValueType == typeof(object))
  {
  string base64representation = SerializationUtility.ToBase64String(detail.Value);
@@ -41,12 +41,18 @@
  {
  detailElement.Write(((LinkDetail)detail).LinkedItem.ID.ToString());
  }
- else if (detail.Value == typeof(string))
+ else if (detail.ValueType == typeof(string))//was detail.Value a typo?
  {
- detailElement.WriteCData(((StringDetail)detail).StringValue);
+ string _value = ((StringDetail)detail).StringValue;
+
+ if(!string.IsNullOrEmpty(_value)) {
+ detailElement.WriteCData(_value);
+ }
  }
- else
- {
+ else if(detail.ValueType == typeof(DateTime)) {
+ detailElement.Write(ElementWriter.ToUniversalString(((DateTimeDetail)detail).DateTimeValue));
+ }
+ else {
  detailElement.Write(detail.Value.ToString());
  }
  }
Index: ElementWriter.cs
===================================================================
--- ElementWriter.cs (revision 501)
+++ ElementWriter.cs (working copy)
@@ -41,7 +41,7 @@
             WriteAttribute(attributeName, value.HasValue ? ToUniversalString(value.Value) : string.Empty);
         }
 
-        private string ToUniversalString(DateTime value)
+        internal static string ToUniversalString(DateTime value)
         {
             return value.ToUniversalTime().ToString(System.Globalization.CultureInfo.InvariantCulture);
         }

</file>
Dec 2, 2008 at 1:43 PM
Yet another related stuff: when inserting previously exported data (on a 4th installation wizard step) example config gets not updated with a root node ID.

The patch:
<file name="20081202-n2-install-fix_root_id.patch">
Index: Default.aspx.cs
===================================================================
--- Default.aspx.cs (revision 501)
+++ Default.aspx.cs (working copy)
@@ -388,6 +388,7 @@
  phSame.Visible = false;
  phDiffer.Visible = true;
  StartId = item.ID;
+ RootId = root.ID;
  }
  break;
  }
</file> 
Dec 5, 2008 at 8:04 AM
Edited Dec 5, 2008 at 8:09 AM
There's even more to this:

I've missed the fact that even having a valid, culture-invariant exported .xml file (with correct DateTimeDetails), the import procedure still needs to force a culture-invariant DateTime parsing. I've noticed that as of revision 508 the whole problem still exists, so prepared a cummulative patch and put it on a google code  
Coordinator
Dec 5, 2008 at 8:30 PM
Oops, I had missed those. Thanks a bunch =)