We need all tables to have a primary key for our database replication solution.

CommentFileSizeAuthor
#10 views_data_export_object_cache_add_primary_-2715565-6-2.patch1.89 KBshura80
#9 views_data_export_object_cache_add_primary_-2715565-6.patch1.89 KBshura80
#7 views_data_export_object_cache_2715565-7.patch1.22 KBheyddi
#6 views_data_export_object_cache_add_primary_-2715565-6.patch1.92 KBDelphine Lepers
#5 views_data_export_object_cache_2715565-5.patch820 bytesDelphine Lepers
#2 views_data_export_object_cache_2715565-2.patch804 bytesrocket777

Comments

rocket777 created an issue. See original summary.

rocket777’s picture

rocket777 commented
StatusFileSize
new views_data_export_object_cache_2715565-2.patch804 bytes

This patch makes the eid column a primary key.

rocket777’s picture

rocket777 commented
Status: Active » Needs review
jrglasgow’s picture

jrglasgow commented

patch in #2 works for me

Delphine Lepers’s picture

Delphine Lepers commented
StatusFileSize
new views_data_export_object_cache_2715565-5.patch820 bytes

Patch #2 works fine, I am submitting a small change: adding a condition for those who had added an index manually

Delphine Lepers’s picture

Delphine Lepers commented
StatusFileSize
new views_data_export_object_cache_add_primary_-2715565-6.patch1.92 KB

My previous patch failed on PHP 7.3 plus Mysql 5.7
Here is a new version that should be compatible. I am creating a new field. In the hook_update i add a workaround suggested in https://www.drupal.org/node/2615496 and in D7 api

heyddi’s picture

heyddi commented
StatusFileSize
new views_data_export_object_cache_2715565-7.patch1.22 KB

Hi!

I have create a new patch to also add primary key on the temp table created during export.

shura80’s picture

shura80 commented

Hello, regarding patch #6 it could happen that the 'views_data_export_object_cache' table is not empty during the table update to add the new 'kid' column, and this would produce an SQL error:

SQLSTATE[22004] Null value not allowed: 1138 Invalid use of Null value

Temporary tables could have still some records that still have been not deleted by the views_data_export_garbage_collect() function called in hook_cron.

So I think it could be more appropriate to do all the job in views_data_export_update_7302 and I propose the attached patch based on patch #6 to ensure that all temporary tables have been cleaned by garbage collector before executing any operation on them.

shura80’s picture

shura80 commented
StatusFileSize
new views_data_export_object_cache_add_primary_-2715565-6.patch1.89 KB
shura80’s picture

shura80 commented
StatusFileSize
new views_data_export_object_cache_add_primary_-2715565-6-2.patch1.89 KB
sadysierralta’s picture

sadysierralta commented

Patch seems to work great!

sadysierralta’s picture

sadysierralta commented
Status: Needs review » Reviewed & tested by the community
steven jones’s picture

steven jones commented
Status: Reviewed & tested by the community » Closed (won't fix)

Sorry for the lack of attention to your issue, please accept my apologies.

Drupal 7 is going to be end-of-life'd by the community in approximately 1 month.

As such, I am closing all non-critical looking, non-PHP compatibility issues for Views Data Export to tidy up the issue queues and reduce the noise. You can read about this on #3492246: Close down Drupal 7 issues.

If you feel like this issue has been closed by mistake, please do comment about re-opening it.
If you feel like the ticket is still relevant for the 8.x-1.x version of the module, then please search for a duplicate issue first, and if there really isn't one (and you've looked properly) then change the version on the ticket and re-open.

Thanks to everyone involved in this issue: for reporting it, and moving it along, it is truly appreciated.
The Drupal community wouldn't be what it is today without your involvement and effort, so I'm sorry that we couldn't get this issue resolved. Hopefully we'll work together in a future issue though, and get that one resolved :)