Database

Bulk Update Customizable Product Options in Magento2

Today I had to bulk-update the Price and Max Characters in the tab Customizable Options for hundreds of simple products based on the title.

I knew that it could be done programmatically but I figured out that it can be done just by updating the table catalog_product_option and catalog_product_option_price. First I got a comma separated list of option_id’s based on a specific title.

SELECT GROUP_CONCAT(option_id SEPARATOR ",") AS option_ids FROM catalog_product_option_title WHERE title = 'Some Message';

1	SELECT GROUP_CONCAT(option_id SEPARATOR ",") AS option_ids FROM catalog_product_option_title WHERE title = 'Some Message';

277,281,284,286,289,292,293,294,295

1	277,281,284,286,289,292,293,294,295

With the comma separated list I was able to update the value of the Price and Max Characters as follows.

1. Price

UPDATE catalog_product_option_price SET price = 5.000 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

1	UPDATE catalog_product_option_price SET price = 5.000 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

2. Max Characters

UPDATE catalog_product_option SET max_characters = 300 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

1	UPDATE catalog_product_option SET max_characters = 300 WHERE option_id IN (277,281,284,286,289,292,293,294,295);

Possible that you have to flush the cache ( php/magento cache:flush ) and re-index everything ( php/magento indexer:reindex ) to see the results.

AWS RDS – You Need (at least one of) The SUPER Privilege(s)

Today I had the opportunity to move a local Magento database to an Amazon RDS. Based on the well-documented article Creating a DB Instance Running the MySQL Database Engine I was optimistic to finish the migration pretty soon. But as you know, there is always something that goes wrong.

After creating the database instance class ( db.m3.large ) I have decided to proceed with some test imports before I change any database credentials in Magento.

$ mysql -h customer.1xcpdspit6hz.ap-southeast-2.rds.amazonaws.com -u customer -p
$ source ~/project_20161014_1135.sql

1 2	$ mysql -h customer.1xcpdspit6hz.ap-southeast-2.rds.amazonaws.com -u customer -p $ source ~/project_20161014_1135.sql

Good decision because the first import didn’t run through.

ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
Query OK, 0 rows affected (0.01 sec)

1 2	ERROR 1419 (HY000): You do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable) Query OK, 0 rows affected (0.01 sec)

I was able to fix the problem by adding the missing parameter log_bin_trust_function_creators as explained here. Before the next import I had to delete the database and create a new one.

ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation
Query OK, 0 rows affected (0.00 sec)

1 2	ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation Query OK, 0 rows affected (0.00 sec)

Unfortunately there was another problem with a DEFINER which tried to create a trigger as a different user. On Amazon RDS only a user with SUPER privileges can do that. Therefore, I had to remove the DEFINER from the MySQL schema you see below.

$ sed -i 's/DEFINER=[^*]*\*/\*/g' project_20161014_1135_toimport.sql

1	$ sed -i 's/DEFINER=[^]\/\/g' project_20161014_1135_toimport.sql

That’s it. Now I was able to import my DB on Amazon RDS without errors.

Query to get size of database tables in MB

If your hosting environment has no database monitoring, you should be able to monitor it manually once in a while or with your own shell script to prevent rapidly growing MySQL tables, because the result of large MySQL tables ( I am talking about 2 – 10 GB with millions of rows ) are often random performance issues, especially if you are using community modules with not well written MySQL queries.

SELECT TABLE_NAME, table_rows, data_length, index_length,
round(((data_length + index_length) / 1024 / 1024),2) "Size in MB"
FROM information_schema.TABLES WHERE table_schema = "{{{YOUR_DATABASE}}}"
ORDER BY (data_length + index_length) DESC;

SELECT TABLE_NAME, table_rows, data_length, index_length,

round(((data_length + index_length) / 1024 / 1024),2) "Size in MB"

FROM information_schema.TABLES WHERE table_schema = "{{{YOUR_DATABASE}}}"

ORDER BY (data_length + index_length) DESC;

This is the output of the query.

| enterprise_logging_event                      |     122389 |    15939572 |      3270656 |      18.32 |
| catalog_product_index_eav                     |     324014 |     4212182 |     18053120 |      21.23 |
| log_visitor_info                              |     182838 |    19706548 |      3599360 |      22.23 |
| catalog_product_index_eav_idx                 |     324014 |     4522245 |     21139456 |      24.47 |
| catalog_product_entity_varchar                |     255303 |    10852180 |     15244288 |      24.89 |
| log_url                                       |     228886 |    10966704 |     15636480 |      25.37 |
| log_url_info                                  |     228886 |    80258352 |      7542784 |      83.73 |
| enterprise_logging_event_changes              |      69184 |   160619752 |      1499136 |     154.61 |
+-----------------------------------------------+------------+-------------+--------------+------------+
586 rows in set (0.05 sec)

| enterprise_logging_event | 122389 | 15939572 | 3270656 | 18.32 |

| catalog_product_index_eav | 324014 | 4212182 | 18053120 | 21.23 |

| log_visitor_info | 182838 | 19706548 | 3599360 | 22.23 |

| catalog_product_index_eav_idx | 324014 | 4522245 | 21139456 | 24.47 |

| catalog_product_entity_varchar | 255303 | 10852180 | 15244288 | 24.89 |

| log_url | 228886 | 10966704 | 15636480 | 25.37 |

| log_url_info | 228886 | 80258352 | 7542784 | 83.73 |

| enterprise_logging_event_changes | 69184 | 160619752 | 1499136 | 154.61 |

+-----------------------------------------------+------------+-------------+--------------+------------+

586 rows in set (0.05 sec)

Table is marked as crashed and should be repaired

Don’t freak out if your Magento is not working and because of the following error message.

SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

1	SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

The reason of a crashed MySQL table is mostly related to a server issue. For example:

Any kind of hard-disk failure
Sudden server reboot (power outage in hosting)
Hard server reboot (ACPI shutdown)

In most cases you can repair the affected table with a simple repair command, which comes with MySQL.

mysql> repair table log_visitor_info;
+-----------------------+--------+----------+----------+
| Table                 | Op     | Msg_type | Msg_text |
+-----------------------+--------+----------+----------+
| magento.log_visitor_info | repair | status   | OK       |
+-----------------------+--------+----------+----------+
1 row in set (0.54 sec)

mysql> repair table log_visitor_info;

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

1 row in set (0.54 sec)

This command looks pretty easy and safe, but keep in mind that you should always create a backup before you change anything in your database, because probably more MySQL tables are affected.