I am having problems importing nodes with CCK image fields.
On our dev server I exported nodes:
% drush dei-ex nodes --content-types=event
From the admin/content I deleted an event node.
Then:
% drush dei-im nodes --file=<datafile>
And I received this error:

WD node: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri': INSERT INTO {file_managed} (filesize, status, timestamp) VALUES (:db_insert_placeholder_0, [error]
:db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 0
    [:db_insert_placeholder_1] => 1
    [:db_insert_placeholder_2] => 1355492845
)
 in drupal_write_record() (line 6975 of /var/www/vhosts/<SITE>/httpdocs/includes/common.inc).
WD php: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri': INSERT INTO {file_managed} (filesize, status, timestamp) VALUES (:db_insert_placeholder_0,  [error]
:db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 0
    [:db_insert_placeholder_1] => 1
    [:db_insert_placeholder_2] => 1355492845
)
 in drupal_write_record() (line 6975 of /var/www/vhosts/<SITE>/httpdocs/includes/common.inc).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry &#039;&#039; for key &#039;uri&#039;: INSERT INTO {file_managed} (filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array
(
    [:db_insert_placeholder_0] => 0
    [:db_insert_placeholder_1] => 1
    [:db_insert_placeholder_2] => 1355492845
)

The node type has a CCK image field, field_event_image, and stores it's files in sites/default/files/event-images/. I took a look at the exported data file, unserialize + base64_decode, and the field_event_image information is all present:
...

   [field_event_image] => Array
        (
            [und] => Array
                (
                    [0] => Array
                        (
                            [fid] => 5988
                            [alt] => 
                            [title] => Event image
                            [width] => 584
                            [height] => 438
                            [uid] => 43
                            [filename] => IMG_0005.jpg_2.jpg
                            [uri] => public://event-image/IMG_0005.jpg_2.jpg
                            [filemime] => image/jpeg
                            [filesize] => 87670
                            [status] => 1
                            [timestamp] => 1337707671
                            [rdf_mapping] => Array
                                (
                                )

                        )

...
The uri is a valid path to the file. I have tried importing the data file both with the image file not present (deleted as per admin/content node deletion process), and with the image copied back to the event-image directory after the node was deleted, and both resulted in the above error and the file_managed table has this as the last entry:

mysql> select * from file_managed where uri like '';
+------+-----+----------+-----+----------+----------+--------+------------+
| fid  | uid | filename | uri | filemime | filesize | status | timestamp  |
+------+-----+----------+-----+----------+----------+--------+------------+
| 7007 |   0 |          |     |          |        0 |      1 | 1355494838 |
+------+-----+----------+-----+----------+----------+--------+------------+
1 row in set (0.00 sec)

Our goal is to use this module to export all of the production site content and import it into our development site to have the latest content, but not overwrite all of the configuration/views/panels etc, but we aren't able to get to that point yet, as our testing of the module on the dev site isn't working.

I am able though, to export the nodes, modify a node title, and then perform an import which will update the node title back to the original.

Is anyone else exporting/importing nodes with CCK image fields with success?

Comments

Countzero’s picture

Countzero commented

Been there, done that : I could almost copy/paste your post. BTW, any CT with files attached seems to behave the same. I'm trying to copy data from a D7 site to a D7 site, which I am in the process of refactoring from scratch.

This module is very interesting, as it is a lot easier to cope with than Migration. I'd be very happy to make it work for this kind of use case, which doesn't need all the rewrite stuff involved in non-Drupal or old-Drupal to new-Drupal migration.

Could you tell us if and when you plan to investigate all this, or should we stick to more complicated and less satisfactory solutions ?

Thanks in advance.

bailey86’s picture

bailey86 commented

OK - let's look at this.

I puzzled as to the use of CCK field. CCK is part of core for D7 and does not need to be installed. So I'm going to assume that you're using the field type of 'file'.

The way the module works is to encode the file contents and add them to the object. Then to re-create the file when importing.

When re-creating the file on the Drupal system there is a difficulty with the file ID (fid) value. It could be that the receiving system already has a file with that fid value. So, the module inserts the file using the API - and then retrieves the new fid number - and then uses that fid number in the tables which link the file to the node.

However, in this case the issue may be simpler as the error is due to the uri value being duplicated. And this entry in the managed_file table looks incorrect.

mysql> select * from file_managed where uri like '';
+------+-----+----------+-----+----------+----------+--------+------------+
| fid  | uid | filename | uri | filemime | filesize | status | timestamp  |
+------+-----+----------+-----+----------+----------+--------+------------+
| 7007 |   0 |          |     |          |        0 |      1 | 1355494838 |
+------+-----+----------+-----+----------+----------+--------+------------+
1 row in set (0.00 sec)

The uri value of "" doesn't seem right - nor does uid of zero. As the uri field looks like it is used as a key then this field should not really have a zero length string as a value - doesn't make sense. And how come we're trying to insert a value with a zero length string for the uri value. This looks like a faulty record.

What I suggest is to get a couple of vanilla test Drupal sites set up - and try to import a single node of the type you need. You can dump out database dump files and diff them with Meld or similar to see what is going on.

The module was heavily tested with D6 as that is where is was first developed - I then converted it to D7 use. It may be that there is an issue with having more than one file field.

I'd like to get to the bottom of what your issue is so any further feedback would be great.

Countzero’s picture

Countzero commented

Don't have time to make serious tests now, but I will soon.

As for my case, and I guess it's true for the OP, CCK means 'Fields'. Just old habits if you ask me.

I can assure the destination doesn't have attached files already. The only record in the table is one like the one listed above (fid=1, size=0, a timestamp and nothing else).

I'm VERY motivated to get to the botton of this too, as it could save my life on a project with a deadline on 01/15.

bailey86’s picture

bailey86 commented

That record in the table does not look right to me. Can you (on a test site) delete that record and try again.

Also, I'd suggest setting up a vanilla D7 site and then testing with a basic content type. Then add in a single file field and test it works OK (this I've done already) and then add in a second file field and test again (which I think I've done). At each point look in the database tables and see what is being generated.

If you want to be able to create new Drupal sites very quickly look at:

https://github.com/SSVC/pullpush

and the script pulld7branchfromdrupal - https://github.com/SSVC/pullpush/blob/master/pulld7branchfromdrupal

This is what I'm working on currently to be able to set up a whole development/deployment server which can take full advantage of the data_export_import module.

Cheers,

Kevin B

fugazi’s picture

fugazi commented

same probleme

bailey86’s picture

bailey86 commented
Status: Active » Postponed (maintainer needs more info)

Is there any feedback from testing after that database record was deleted?

Countzero’s picture

Countzero commented

Sorry for the late report : I tried emptying the table (the record was indeed there), but to no avail.

I had to go on, so switched to another solution.

bailey86’s picture

bailey86 commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Seems strange that the error RE the key for URI should re-appear after all files have been deleted.

The key error seems to be 'Duplicate entry '' for key 'uri':'

It may be that the suggestion in http://drupal.org/node/1922600#comment-7363316 would be useful here.

There do seem to be a couple of issues RE importing nodes with attached files clashing with existing file records in the database. My thinking is that records are not being imported into a clean Drupal instance and that existing file records in the database are causing errors.

Obviously, there may be something else but I'm going to mark this as 'closed (cannot reproduce)' for now. Please feel free to re-open the issue if there is any further feedback.

bailey86’s picture

bailey86 commented
Status: Closed (cannot reproduce) » Active

I've re-opened this as I've been able to reproduce the issue. I've got what looks like a fix.

It was basically because for this module I only exported/imported fields of type 'file' - but D7 also has a field of type 'image'.

Please note this fix is not fully tested yet but I've exported and imported and it looks OK.

Here's my comment from another bug report.

OK.

I have some changes which on a quick check look like a fix.

For the D7 code.

In the file nodes.inc

On lines 165, 276, 617, 761 change

if ($type == 'file') {

to

if ($type == 'file' || $type == 'image') {

and this looks like it's working.

Please test this an let me know how it works for you.

bailey86’s picture

bailey86 commented
Status: Active » Fixed

This should be fixed in 7.x-7.2.

The key bit I missed in the original bug report was that this was for 'image' fields - the module was originally developed and heavily tested on D6 - I didn't realise D7 had another field type which held files.

bailey86’s picture

bailey86 commented
Status: Fixed » Closed (fixed)