Posted by Bevan on August 24, 2011 at 10:16am
6 followers
| Project: | Views data export |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
With a solr-index view where the Data export display is configured to use batched export, I consistently get the following error when trying to export the file:
Fatal error: Call to a member function addMetaData() on a non-object in .../sites/all/modules/contrib/views_data_export/plugins/views_data_export_plugin_display_export.inc on line 734
I started to look a bit closer; $view->build_info is in it's initial state, as though $view->build() had not executed. However calling $view->build() does not turn $view->build_info['query'] or $view->build_info['count_query'] into SelectQuery objects. They are still empty strings.
I did not look further.
Comments
#1
Yeah...this module isn't going to work with a Solr backend, as it needs the SQL to do the export magic. We should have made this more clear, and not let you use it on a non-SQL base table, but when we originally wrote the module this part of views wasn't stable and we couldn't reliably detect base tables we could be applied to safely.
We should.
#2
Most of the module works with the solr backend. Only some features are broken. Perhaps just those features can be disabled with non-SQL views backends?
#3
So is it only with batched that it breaks?
#4
rooby: There may be other features which are broken with non-SQL views backends such as Solr-indexes. I did not find any, but I did not look hard either.
#5
Yeah, for my usage it is working OK without batching.
#6
As Crell said in #1532472: Hard-coded dependency on SQL Views query plugin, batched export should be made available for any query back-end. I could try to work on it. Has someone any idea on where and how to start?
#7
Currently, it only works when the query plugin is views_plugin_query_default. Search API declares its own query plugin: SearchApiViewsQuery.
I don't really know what would be the best way to do what I want. As far as I understand, the query is done at the beginning of the batch process, and the result is stored in a database table. Then, each batch iteration renders an amount of results.
This logic could be kept, but the implementation might be pretty different. If I'm right, results storing is done with this statement:
<?php$insert_query = 'CREATE TABLE {' . $display_handler->index_tablename() . '} SELECT @row := @row + 1 AS ' . $display_handler->batched_execution_state->sandbox['weight_field_alias'] . ', ' . implode(', ', $select_aliases) . ' FROM (' . (string)$query . ') AS cl, (SELECT @row := 0) AS r';
?>
This works because initial query is SQL. But of course this won't work for a Solr query.
And if we manage to get the results in the database in the same format, will that be OK with no changes to the rest of the code? Will rendering work? I don't know well how Views code works, which confuse me a bit actually. I don't want to lose much time in wrong ways. So, any help from a maintainer would be greatly appreciated.
#8
Really sorry, the code is amazingly messy, and we've been always meaning to refactor the whole thing. We're attempting to carve out some time so that we can give this a couple of weeks of proper development.
#9
OK, thank you for the answer. I suppose this means we just have to wait. Any idea about when it would be available (at least in dev)? For me to know if I have to find another way right now (custom code, switch to SQL backend, tell the customer it won't work for big exports,...) or if it will be done before project deadline.
#10
I could not wait more. Here's the hack I did to have it work with Search API Views. Not easy.