-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Users are sometimes unable to create database tables but we don't tell them #121
Comments
At least part of the solution here is to tell users what the SQL query is to create the tables, so they can send it to their host. table one
table two
|
At least some of this is because they are using MyISAM instead of InnoDB link here. The table creation will fail for MyISAM users because the key To fix this we should try to create the table as it is (because Salesforce can use a lot of characters and this should absolutely be our default), and if it fails because the key is too long we should try again with a limit on the key of 1000 bytes. Right now the key length is up to 383 (128 wp object name; 255 sf object name) characters, and they're all varchar. So presumably it wants 1149 bytes and MyISAM won't do it. We would need to cut 50 characters for those users. However cutting only 50 doesn't work. I got it to work with this: Alternatively we could just force InnoDB on these tables, or not do anything. I need to think more about this. |
…e the index is too long for MyISAM.
The easiest way to keep allowing users to run MyISAM without messing up Salesforce data configurations for everyone else would be something like this, in activate.php:
However this has a couple of issues:
I think for now it's best to just force InnoDB on that table. This will get released in the next plugin update. |
I'm going to close this for now. It is theoretically possible that users might have more reasons that tables aren't created, but we'll cross that when we get there. I think the majority just have a default of MyISAM. |
I think we also need to investigate this utf8mb4 stuff. https://make.wordpress.org/core/2015/04/02/the-utf8mb4-upgrade/. |
Thanks for this note, it helped me get up and running. I encountered this bug as well. For me, it manifested as a generic error when trying to save field maps. I finally traced it to a missing table (wp_object_sync_sf_field_map). I used the SQL code above to create the table manually but that didn't quite work. It turns out that since it was posted there is a new column in the table (version). When I created that, things worked fine. So, here is the SQL code to create the wp_object_sync_sf_field_map table that worked for me in case it can help others.
|
@mistermarco thanks for the reminder there. I'm curious if PHP or MySQL ever returned error messages, especially during the activation of the plugin? Did it tell you why it was unable to create the tables? And was it only the field map table that it failed to create, or both? |
PHP didn't show any errors, and I don't have access to the MySQL error log (this is on Pantheon, and I actually found out it's MariaDB - not sure if that makes a difference). It only failed to create the wp_object_sync_sf_field_map table. I'm trying to set up an identical environment locally to see if I can reproduce this issue reliably. |
Hi, Still doesn't work. Missing columns error. |
@andygagnon I don't have the space to look through days of error logs for you. This issue is not regularly updated when the plugin changes, so here are the current table structures. You may be able to just use them without worrying about your logs. Although I've seen this plugin work well in Pantheon, so you may have other issues.
|
Thank you. Deleted and re-created mysql tables. Works now. Missing column was 'pull_to_drafts'. Here are the highlights from the error log that may help solve this problem long term. My apologies for the large data dump. At plugin install, this is the critical error on Pantheon. [04-Mar-2019 14:55:39 UTC] WordPress database error Index column size too large. The maximum column size is 767 bytes. for query CREATE TABLE wp_object_sync_sf_field_map ( After that, can't write to a non-existent table, [04-Mar-2019 15:00:08 UTC] WordPress database error Table 'pantheon.wp_object_sync_sf_field_map' doesn't exist for query SELECT Created table from SQL I referred to previously, but it was missing pull_to_drafts column. [06-Mar-2019 21:17:51 UTC] WordPress database error Unknown column 'pull_to_drafts' in 'field list' for query SELECT Deleted and created 2 new tables, per your SQL. Creating fieldmaps works now. Thanks for your time. |
I've added a new section in the documentation that contains the SQL for creating tables when they're missing. It is located here. My hope is that this can be maintained if and when the SQL changes, and that users will be able to refer to that document any time they have this issue. I've made this instruction in code as well in 5cc560e. I'm also hopeful that it'll happen less and less, but I'm still unclear exactly what conditions - aside from out of date versions of MySQL - cause it to happen. |
One further thing that came up in this forum post is that one possible cause is that hosts might not have I don't have any space to build out that kind of compatibility into this plugin, and I don't foresee that ever changing, but it would be nice to check for that feature's presence during the activation process. Then we could help those users avoid getting too far into this for no reason. |
Just want to chime in that I encountered this problem when trying to create
One suggestion was to change the But MySQL will only allow one column to have one
|
@jrfoell one thing I observed in trying to understand #291 is that the If it is, I would certainly review a pull request that checked MySQL versions or capability in order to make it work for those users, but it's very unlikely that I would have the capacity to do that work myself. |
I see some questions in the support forum where users try to activate the plugin, but it doesn't create the correct database tables.
Currently the plugin fails silently when this happens, but it won't ever successfully connect to Salesforce.
I think we need to put something into the activate process to check for whether the tables were successfully created, and if they weren't show the user some messaging. Ideally we could find out why the tables weren't created - whether the server user didn't have permission or what - but we should show whatever we know at that point.
database tables
As of 3/7/2019, this is the table structure the plugin needs to create:
The text was updated successfully, but these errors were encountered: