export failing on large set set_display() on a non-object

Did you ever resolve this malinica? I'm getting exactly the same thing (version 7.x-3.0-beta5).

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=100&op=do StatusText: OK ResponseText: Fatal error: Call to a member function set_display() on a non-object in **\public_html\sites\all\modules\views_data_export\views_data_export.module on line 148

It's really random, sometimes it works, sometimes it doesn't.

Actually, I added more fields and I get this error all the time now. Also, the Reset button on the exposed View filters triggers the Excel export.

Subscribed.

subscribe....

I appear to get getting the same thing on csv export. When exporting in batch mode, I get:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=150&op=do StatusText: OK ResponseText: Fatal error: Call to a member function set_display() on a non-object in /home/revo/public_html/sites/all/modules/views_data_export/views_data_export.module on line 148

When I get this, I also see this in the logs:

Notice: unserialize() [function.unserialize]: Error at offset 54486 of 54489 bytes in views_data_export_view_retrieve() (line 243 of /home/revo/public_html/sites/all/modules/views_data_export/views_data_export.module).

line 243 is in this code:

/**
 * Retrieve a view from the object cache.
 */
function views_data_export_view_retrieve($export_id) {
  views_include('view');
  $data = db_query("SELECT * FROM {views_data_export_object_cache} WHERE eid = :
eid", array(':eid' => $export_id))->fetch();
  if ($data) {
    $view = unserialize($data->data);
  }
  return $view;
}

The $view = unserialize($data->data); line is line 243.

I put a dpm($data) before the if statement, and reran the export. I got 2 $data displays, one with a data field 242179 chars long, and one with a data field 54489 chars long. The latter is obviously the one where the unserialize is failing. The last 4 chars (chars 54486 through 54489, as the unserialize error shows the failure at char 54486) are 's:9:"', which is an incomplete 9 character string specification. The data appears to have been truncated.

Lines 147 and 148 (148 is the point of the first failure message) are:

  $view = views_data_export_view_retrieve($export_id);
  $view->set_display($display_id);

It appears that what is happening is that, since the unserialize fails, views_data_export_view_retrieve returns a non-object (probably null), and therefore the call to set_display fails. The real problem is that the data in the 'data' field of the views_data_export_object_cache table is truncated.

Does that help anyone track this one down?

I'm beginning to wonder if this is a problem in drupal_write_record (which is used to write the record to views_data_export_object_cache on line 233). I played with this a bit, and found that, for a given field setup, the unserializable data field was always the same length. Changing the number of fields changed the size of the unserializable data field, but for a given setting, it is still the same length.

The truncation *does* always seem to occur in the same field. I dug through the dpm of the view as it was before being written by drupal_write_record (it's shocking how much redundant data there seems to be in it), and found the field where the truncation occurs. The is at

$_view->localization_plugin->view->query->table_queue['taxonomy_term_data_node']['join']->definition['table formula']

in the $_view variable in views_data_export_view_store. On this site, this field appears (from what's on the dpm) to be a SelectQuery_pgsql object (I ran across this while putting together a patch to enable batch-mode export with PostgreSQL).

Could someone else who is running into this problem on a site running MySQL do a similar test, and see if you come up with the same data? I did this by putting a 'dpm($_view)' just before the drupal_write_record in views_data_export_view_store, and a 'dpm($data)' just before the if in views_data_export_view_retrieve. I then run the failing data export in one browser tab, and when it dies, do a 'recent log messages' on another browser tab. The log message page should pick up the dpm messages from the data export. The last dpm message for $data should allow you to see the contents of the data field. You should also see a log message for the unserialize failure.

For comparison purposes, the last couple of lines at the bottom of my sample $data display was

s:10:"left_table";s:4:"node";s:10:"left_field";s:3:"nid";s:5:"field";s:3:"nid";s:4:"type";s:4:"LEFT";s:13:"table formula";O:17:"SelectQuery_pgsql":19:{s:9:"

If someone else can confirm that this is the issue under MySQL, maybe we can narrow down this issue.

Can you upgrade to beta6 and see if you can reproduce this issue?

Sorry, not had a response for a long time.

Hi,
I am using postgres and I also am getting hit by this issue. I have 3 views using views_data_export, and two of them work fine in batch mode, but the third one fails as above during export.

I also get the message in my watchdog indicating that the unserialize of the data fails. I'm not sure but I think this might be something to do with the fact that the data is stored as text:big (postgres text) or possibly with drupal_write_record as @ben reports above. Looking in the database the data is cut off after 100348 characters, so the unserialize is failing.

Should we be storing this data in a bytea (blob) as you do with the sandbox for the table views_data_export? I will try to investigate ffurther. Reopening and will try to report back.
K

I have the same issue as mentioned above... When I have time, I will look into it and see if I can provide a patch to make it work on a PG backed site

I can confirm that the following change fixes the exports for me. I'm dashing off now and don't have time to make a patch.

alter table views_data_export_object_cache drop column data;
alter table views_data_export_object_cache add column data bytea;

Patch attached with the above fix against current head / 7.x-3.0-beta7

This time with the patch going in the right direction!!!

This does indeed fix the problem for us. Thank you!

I was very happy to see that there's been progress on batch exporting in postgres, then went to test it and hit this Fatal error before the batch process started. After applying the #14, my export ran perfectly and I was able to export 2200 users in under a minute. Thanks a lot!

#14 fixed also my problem ! Thanks !

Very cool, thanks for the patch, and thanks for the reviews everyone.