Import XML Data Topic

Friday 03 November 2006 5:22:55 am

If the parser does not return an object then you can get any parsing errors with

$errors = $parser->getMessages();

and print them

foreach ( $errors as $error )
{
    $cli->output( $error );
}

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Sunday 19 November 2006 5:02:07 pm

Hi Maurizio

my xmlimport extension should be able to do this. it isn't published in the contributions yet; i'm waiting for a response from olivier pierret. it's tested with the 'objectrelationbrowse' datatype, but 'objectrelation' and 'objectrelationlist' should work, too.

take a close look at these screensnaps:
http://pike.kw.nl/browse/files/projects/pike/2006/ezpublish/XMLImport/screensnaps
and notice the relations in the xmlfile.

as you see, relations are nested. inside the tag of the relationattribute, there are entries of the right datatype with a set of fields that should together form a unique identifier of the related resource. the importscript will perform a search on those. if it finds multiple applicable objects, it will return a warning and use the first one; if it doesn't find any applicable object, it will only issue a warning. see the output screensnaps for examples. ofcourse, the related object should have been imported before the relating object, it should already exist.

if you think you need this, contact me (pike-ez [AT] kw.nl)

*-pike

---------------
The class eZContentObjectTreeNode does.

Tuesday 21 November 2006 2:01:49 pm

Hi Maurizio

a complicated story, as usual with encodings :-)

in your office, mysql4, ezp3.7,
- stuff in the browser looks ok
- the mysql source seems (?) ok

at your clients office, mysql unknown, ezp3.7,
- there are strange characters in the browser
- the mysql source seems (?) ok

then you notice something else:

in your clients database,
- strange chars inserted via the admin get some encoding
- strange chars inserted via the import are stored literally

in your own database,
- strange chars inserted via the admin are stored literally
- strange chars inserted via the import are stored literally

is that all correct ?
so at both offices, working with the admin is no problem,
but the databasecontent is different, one 'literally', one
'with some encoding'.

i have no clue :-)) but consider where you want to go.
do you want to

- keep working at your clients office with that encoding, iow
- leave their setup (and admin) as it is
- find out what goes wrong with the import, or

- get everything working at the clients office like in your own office, iow
- compare their setup with yours, make it the same
- leave the importscript as it is, probably working by then

I would go for the 2nd option, compare the mysql version, ini files,
ezp settings, line everything up. there must be some difference.

*-pike

ps. did you add the <?xml header to your import file ?

---------------
The class eZContentObjectTreeNode does.

Tuesday 20 February 2007 10:44:50 am

Hello,

I try to integrate ImportXMLData contrib in a multi-langague site and I want to know if somebody has an idea on positivity to add the option to select site language in the imported xml data.

Sorry for my English

Saturday 31 March 2007 2:33:58 am

Hi Mauricio

Yes, there's been more post about the memory issue. There are 2 big factors in ImportXMLData: parsing the xml file and creating new objects.

I've loaded files of 900k with a 256Mb memory limit. It was slow, but it worked.
But when creating new objects, every object stays in memory (sortof). This can be improved in the script, but not taken away completely; something happens deeper in the kernel that eats memory for every created object.

>I added: $attribute->setAttribute("data_text",utf8_encode($xml_content_string))
>To the importXMLDatafunctioncollection.php file to import the norwegian letters into the >database.

good tip, thanks.

>Any solutions?
>Commandline? or other fixes.

I dont think commandline will help much (but havent tried). See
http://ez.no/community/forum/developer/memory_leak_on_content_publish
for other possible solutions. No final solution though ...

$2c,
*pike

---------------
The class eZContentObjectTreeNode does.

Tuesday 24 April 2007 5:57:02 am

----moderated: spam---

Tuesday 25 December 2007 8:15:51 pm

Merry Christmas.

Does this extension work on eZ 4.0?
I tried to import some data, but got these errors:

Error: eZModuleFunctionInfo::execute  	Dec 26 2007 01:35:49

No class 'XMLImportFunctionCollection' available for function 'XMLImport' in module 'XMLImport'

Error: eZTemplate  	12�� 26 2007 10:20:02

Cannot retrieve attribute of a NULL

How can it work on PHP 5?

Please...

Shinetech is the leader in next generation global application outsourcing. Shinetech combines world class technical skills, recognized expertise in advanced development methodologies and industry experience to deliver results for global enterprises. Shinetech utilizes distributed Agile methods for rapid and precise systems development.
------------------------------------------------------------------------------------------
Blog: http://www.mingxing.me
Email: chenmx@shinetechchina.com

Monday 06 September 2010 4:51:02 am

Hi Andy

You may consider SQLIImport : http://projects.ez.no/sqliimport :)