2 bugs, plus indexing in correct language

Thanks for the patch! Looks good on the whole, just one thing:

+++ b/datasource.inc
@@ -161,7 +160,7 @@ class SearchApiEtDatasourceController extends SearchApiEntityDataSourceControlle
+      foreach (search_api_et_item_languages($entity, $entity->entityType, $index) as $lang) {

Why should this work? Entities don't have that property, at least not in general.

Revised patch attached.

With all the patches in the issue queue applied, I can successfully create an index based on node (multilingual), set fields, workflow and finally build the index.

Building the view generates an ajax-error on adding a field or filter:
EntityMetadataWrapperException: Invalid data value given. Be sure it matches the required data type and format. in EntityDrupalWrapper->set() (line 744 in sites\all\modules\entity\includes\entity.wrapper.inc).

Hi,
Thank you for committing the patches into one package... that is very convenient.
I tried your sandbox version and I've managed to create a simple page succesfully with search_api_page.
But when I build a search page again via views, I'm still receiving the same error message on adding a field or a filter:
- with display format 'rendered entity' (display search result), and
- with display format 'fields'
Are there certain conditions (minimum versions) for modules like entity or views?
Sincerely,
d3claes

Hi,
Yes, we are one step further.
This is the sql error message I'm receiving when adding a field to the view:
PDOException: SQLSTATE[22018]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Conversion failed when converting the nvarchar value 'fr_1339' to data type int.: SELECT revision.[vid] AS [vid], base.[uid] AS [uid], revision.[title] AS [title], revision.[log] AS [log], revision.[status] AS [status], revision.[comment] AS [comment], revision.[promote] AS [promote], revision.[sticky] AS [sticky], base.[nid] AS [nid], base.[type] AS [type], base.[language] AS [language], base.[created] AS [created], base.[changed] AS [changed], base.[tnid] AS [tnid], base.[translate] AS [translate], revision.[timestamp] AS [revision_timestamp], revision.[uid] AS [revision_uid] FROM {node} base INNER JOIN {node_revision} revision ON revision.vid = base.vid WHERE ( ([base].[nid] IN (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9)) ); Array ( [:db_condition_placeholder_0] => fr_1001 [:db_condition_placeholder_1] => fr_1010 [:db_condition_placeholder_2] => fr_1011 [:db_condition_placeholder_3] => fr_1014 [:db_condition_placeholder_4] => fr_1053 [:db_condition_placeholder_5] => fr_1271 [:db_condition_placeholder_6] => fr_1317 [:db_condition_placeholder_7] => fr_1332 [:db_condition_placeholder_8] => fr_1335 [:db_condition_placeholder_9] => fr_1339 ) in DrupalDefaultEntityController->load() (regel 203 van C:\doc-drupal\includes\entity.inc).
The language is still part of the passed id's.

It is difficult to follow the functions one after each other because many classes are being extended, etc.
In #10, the call to entity->load that is raising the error message is in line 470 of sites/all/modules/search_api/contrib/search_api_views/includes/query.inc. The parameter $results passed to this function get_result_wrappers($results, $relationship = NULL, $field = NULL) has the language part in the id's.
It is not the fct. getMetadataWrapper() in datasource_entity.inc from your sandbox that generated the fault.
When I extract the id-parts similar at line 470, the view get build correctly.

I've used the patch in https://drupal.org/node/1937832 to create a 'stacktrace' and 'backtrace', if this is of any help:
stacktrace:

backtrace:

Although it's not mentioned as such in the above lists, the fct. getMetadataWrapper() in datasource_entity.inc gets called twice per node (print_r($item)):
- first time with $item = language_nid (which get cleaned up by explode() above it)
- second time with $item = entity-object
First all the nids get passed, then the objects

Caches were emptied, and index and view were fresh build.

I can confirm that with this latest patch no errors/notices are raised during the building of the index, the creation of the view and the use of the view.
Thank you very much!

I will do some additional testing on building and using the view (available fields and exposed filters)... but that's beyond this issue.

I've committed the patch in #4. Thanks again!

Regarding the other fixes in your sandbox: have you posted patches for those in my issue queue, too? I do think we should keep things in one location, if possible. I'd be happy to give you committ access to this sandbox, too, however, if you want. Or, if your sandbox is already more or less finished, we can just ask Daniel whether he wants to commit that, and if I have things to add I can then just create issues for the main project.