Postgres issues

parent_entity_id should have a default value in the install file. I set it to 0, but did not review possible consequences yet :).

Hi guys,

I have same issue with Oracle.
I think it should be fixed in next version.

It is affecting 7.x-1.x-dev.

Set in 'apachesolr_index_entities_file' columns 'parent_entity_id' default to 0 and 'parent_entity_type' default to ''. Seems to be a workaround, but looking further in the code it seems to cause some side effects (e.g. wrong file usage count). Below goes a code where it might be a problem.

// Retrieve parent entity id and add its file usage
+            list($parent_entity_id) = entity_extract_ids($parent_entity_type, $parent_entity);
+            apachesolr_attachments_add_file_usage($file, $parent_entity_type, $parent_entity_id);

When a I try to uninstall this module in Postgres I also get this erro:
PDOException: SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: character varying % unknown LINE 2: WHERE (name % 'apachesolr\\_attachments\\_enity\\_bundle\\_... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.: DELETE FROM {variable} WHERE (name % :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => apachesolr\_attachments\_enity\_bundle\_indexing\_ ) in apachesolr_attachments_uninstall() (line 26 of /var/www/html/drupal/sites/all/modules/apachesolr_attachments/apachesolr_attachments.install).

This error seems to be a typo

function apachesolr_attachments_uninstall() {
db_delete('variable')
->condition('name', db_like('apachesolr_attachments_enity_bundle_indexing_') , '%', 'LIKE')
->execute();

where it should be:

function apachesolr_attachments_uninstall() {
db_delete('variable')
->condition('name', db_like('apachesolr_attachments_enity_bundle_indexing_') . '%', 'LIKE')
->execute();

I'll do some tests here and investigate it further.

Seems to me that this issue is caused by this MySQL peculiarity. As the document states, we are going to the wrong way to fix it.

When porting code that relies on MySQL implicit default values to other databases, it is tempting to "fix the problem" by indiscriminately adding a default value to all columns, thus mimicking MySQL's sloppy behavior. This practice is discouraged. There is nothing wrong with default values, but columns should only have a default value when it makes semantic sense for that particular table. Instead of adding an illogical default value to a column, just fix the INSERT queries for that table by providing values for all columns. In the example above, change the query to read INSERT INTO T (i1, i2) VALUES (NULL, 0).

Looking it further, I found out that apachesolr module have to create a generic item in 'apachesolr_index_entities_file'. So, we have to provide a default value to 'parent_entity_id' and 'parent_entity_type' and it will make semantic sense. Doing some tests in mysql (version 5.1.29), I also found out that they were set then to 0 and '' as default before I use the patch.

In attached the patch that set in 'apachesolr_index_entities_file' columns 'parent_entity_id' default to 0 and 'parent_entity_type' default to ''. And fix 'apachesolr_attachments_uninstall' typo described in #3.

I did some tests in postgresql and mysql and seems to worked fine.

Shouldn't it be "apachesolr_attachments_entity_bundle_indexing_" rather than "apachesolr_attachments_enity_bundle_indexing_", in the code given above ?

function apachesolr_attachments_uninstall() {
db_delete('variable')
->condition('name', db_like('apachesolr_attachments_entity_bundle_indexing_') . '%', 'LIKE')
->execute();

updated patch/fix for this can be taken from https://www.drupal.org/project/apachesolr_attachments/issues/2677866