Cannot install on mysql >= 5.6

I have the same problem too.
The patch #3 works for me.

Does this need an update function?

Also - it's not clear to me if this index matters for performance of any queries?

Hello,

I have 2 concerns about this patch:

1. Like @pwoalnin says, the patch should foresee a hook_update because existing sites will have a schema definition that is not aligned with what is actually defined the DB;
2. Before the patch, we had a combination of 3 columns to define the primary key of a record and now, we have only one.
   Before, I could have several rows in the table with the same entity_id but with different 'parent_entity_id' and/or 'parent_entity_type'; with the patch, it is not possible anymore as the table cannot have several record with the same 'entity_id'.
   I see in the module code (see apachesolr_attachments_entity_update() && _apachesolr_attachments_get_all_files()) that if the entity has the "file" type, we could have several records pointing to the same entity_id but a different parent. So, in some cases, the patch will generate "MySQL primary key violation" exceptions at insertion time.
   So, IMO, the option 2 is risky and we should investigate the option 1.

I will come ASAP with more output about the second concern to confirm it or not, and also with a way to implement the option 1.

Ok. I confirm that the option 2 is not working when we use the "File entity" and "Media" modules.

I get this exception:
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '3' for key 'PRIMARY': INSERT INTO {apachesolr_index_entities_file} (entity_type, entity_id, parent_entity_type, parent_entity_id, bundle, status, changed) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => file [:db_insert_placeholder_1] => 3 [:db_insert_placeholder_2] => node [:db_insert_placeholder_3] => 2 [:db_insert_placeholder_4] => document [:db_insert_placeholder_5] => 1 [:db_insert_placeholder_6] => 1487056367 ) in apachesolr_attachments_add_file_usage() (line 220 of /[...]/modules/contrib/apachesolr_attachments/apachesolr_attachments.index.inc).

Step to reproduce:

1. Applying the patch;
2. Enabling "Apache Solr search", "Apache Solr search attachments", "Media" (7.x-2.0-beta1) and "File entity" (7.x-2.0-beta2);
3. Configuring "Apache Solr search attachments" in order to use Tika;
4. Creating a content type with a file field using the media browser
5. Creating a content with this content type where we add a file via the media browser interface;
6. Saving the content;

The exception occurs during the content saving because the file has been indexed already in the table when it has been save through the media browser without any related parent.
When we save the content, the module tries to save a new entry with the same file entity id but with a related parent.
So, the system can managed the reuse of a file in different contents or its use without parent if the Drupal instance is set for it.

Definitively, the option 1 is the only option... that I see so far :-)

I will work on the patch

I tested the following patch #10 with MySQL 5.6.28 and 5.6.34 and it works on my environments.

Could you please confirm if it's work for you too?

I've spent some time to investigate this issue. It seems that for the MySQL version 5.6 family problem doesn't appear. I've checked and indeed there is a problem during installation for the MySQL version 5.7 following error appears:

PDOException: SQLSTATE[42000]: Syntax error or access violation: 1171 All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead: CREATE TABLE {apachesolr_index_entities_file} ( `entity_type` VARCHAR(128) NOT NULL COMMENT 'The type of entity.', `entity_id` INT unsigned NOT NULL COMMENT 'The primary identifier for an entity.', `bundle` VARCHAR(128) NOT NULL COMMENT 'The bundle to which this entity belongs.', `status` INT NOT NULL DEFAULT 1 COMMENT 'Boolean indicating whether the entity is visible to non-administrators (eg, published for nodes).', `changed` INT NOT NULL DEFAULT 0 COMMENT 'The Unix timestamp when an entity was changed.', `parent_entity_type` VARCHAR(128) NULL DEFAULT NULL COMMENT 'The type of entity.', `parent_entity_id` INT unsigned NULL DEFAULT NULL COMMENT 'The type of the parent entity.', `hash` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'A hash of the file’s body, to check for changes.', `body` LONGBLOB NULL DEFAULT NULL COMMENT 'The cached body (extracted text) of the file, unless it is a text file.', PRIMARY KEY (`entity_id`, `parent_entity_id`, `parent_entity_type`), INDEX `changed` (`changed`, `status`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Stores a record of when an entity changed to determine if...'; Array ( ) in db_create_table() (line 2776 of ../includes/database/database.inc).

I've rerolled the https://www.drupal.org/files/issues/mysql-56-compatibility-2677866-10.patch patch (empty line at the end of the file was missing) and after appling it I didn't notice any errors during the installation for the MySQL version 5.6 and 5.7.

Have tested patch #12 on MySQL 5.7.22-0 on a Ubuntu 16.04.1 and the patch works fine.

Patch #12 worked for me on MySQL v5.7.25

Please find the updated patch created against 7.x-1.4 & includes an hook_update_N as well.

Patch #15 works fine with 7.x-1.4 & for MySQL > 5.6 and MariaDB 10.6

few similar issues are listed below
https://www.drupal.org/project/apachesolr_attachments/issues/2803667
https://www.drupal.org/project/apachesolr_attachments/issues/2991156
https://www.drupal.org/project/apachesolr_attachments/issues/2825094
https://www.drupal.org/project/apachesolr_attachments/issues/1864338