Indexing an aggregated field fails with SQL error

Moving to correct project.

I'm getting this error message when cron is ran

"Fatal error: Unsupported operand types in sites/all/modules/search_api/contrib/search_api_db/service.inc on line 495"

Using latest dev. versions of entity, search_api and search_api_db.

Now i also get the message "Couldn't index items. Check the logs for details."

Using latest dev. versions of entity, search_api and search_api_db.

Can't be true, as the latest version of search_api hasn't got the search_api_db module in contrib/ any more. Make sure that this directory (as well as contrib/search_api_page/) is deleted.

you are right!

Now that it's replaced, I still get the error "Couldn't index items." :-/

SearchApiException: No field settings for index with id default_node_index. i SearchApiDbService->indexItems() (linje 306 av /sites/all/modules/search_api_db/service.inc).

@ #4: Did you have the very latest search_api_db version installed (Beta 2 now)?
The latest releases (betas and RCs) of all my own Search API-related modules should work fine together.

now I have the latest version, (beta 2 ) and the error message went away! thank you sir! :-)

It looks like the error reported in #2 is a different issue than the original issue. So while it is great that issue is resolved by the most recent release, I am still running into the same issue reported in the original post using beta 2. I see the following errors when indexing with an aggregated field.

Notice: Undefined index: search_api_aggregation_1 in SearchApiDbService->indexItem() (line 333 of /sites/all/modules/search_api_db/service.inc).

and

Notice: Undefined index: search_api_aggregation_1 in SearchApiDbService->indexItem() (line 332 of /sites/all/modules/search_api_db/service.inc).

and

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE (item_id = '4666')' at line 1

I will ultimately be deploying this with solr, so it is great to hear that there is no problem there, but it seems like this should also work using a database index.

same problem here. any idea how to solve it?

after a bit of investigation the problem seems due to

$fields = $this->options['indexes'][$index->machine_name];

at line 328 that does not return the aggregated field in the fields array.

I had some time to look into this last night. It looks like part of the problem is, as noted in #11, that $this->options['indexes'][$index->machine_name] does not contain the aggregated field which causes the undefined index notices. The other part of the problem is that an index table is never created for the aggregated field in the database, so that when it tries to save the values to the index it generates the SQL error because the table does not exist.

Both of these issues appear to be due to the way the $this->options['indexes'][$index->machine_name] list of fields is generated. $this->options['indexes'][$index->machine_name] is a reference to the server entity's options property, which appears to be created by the addIndex() method and modified by the fieldsUpdated() method. Both of those methods use SearchApiIndex::getFields() to generated the list of fields, both for options as well as when generating index tables. Aggregated fields are not returned by that method, so they are not included.

I am not yet familiar enough with the Search API family of modules to offer a solution, but hopefully this will point someone else in the right direction.

Has anyone find a solution in #12 issue ? I'm using Database search 7.x-1.0-beta2 and Search API 7.x-1.0 modules I'm getting the same error when indexing with an aggregated field.

I figured this one out, or so I think...

• Creating an aggregated field (via the Workflow tab) will not create the table. This is only done when enabling the field to be indexed (via the Fields tab)
• However, it seems that the first "aggregated field" you create gets automatically set to "indexed" (check the Fields tab), without creating the table
• So, to trigger the table creation, you should disable/enable or update the field.
• Any other aggregated fields you add thereafter will not be automatically set to "indexed", so no problem there.

So the solution should be to not set the aggregated field to "indexed" the first time. The work-around is to disable/enable it in the Fields tab...

thanks BenVercammen

your solution @ work here.

Posting that the work around works for me, but a real fix would still be nice. Thanks!

Please test the patch in #1414138-10: Notice: Undefined index: search_api_access_node for the Search API, which should solve the issue. (Re-enable the data alteration after applying the patch.)

thanks BenVercammen

your solution worked for me as well.

The same message occurs for me without using an aggregated field. I'm indexing some taxonomy reference fields with multivalue; in a particular taxonomy (I dunno why) I got a similar error:

Unsupported operand types sites/all/modules/search_api_db/service.inc:540

I've debugged I little bit and I've found that in some cases $value (service.inc:540) is not a singular item but an array of items. So I've thought to do a patch in this way:

+        if (is_numeric($value) || !$value) {
+          return 0 + $value;
+        }
+        elseif (is_array($value) && isset($value[0])) {
+          return $value[0];
+        }
+        else {
+          return 0;
+        }
-        return 0 + $value;

I'm sure that this is not the best way to solve the issue but after a re-index I got everything working as expected.
Attached my patch that needs more tests.

I set the priority to "critical" because without this patch I can't do an indexing.

@ sardbaba: This is a different problem, please create a new issue for that.
Also, issues which only occur for few users aren't “critical”.

@ others: Do you still have this issue with the latest Beta (4)?