Hi Sebastien,
Thanks for replying to this call.
The version of the mysql database is below:
mysql> SHOW VARIABLES LIKE "%version%";
+-------------------------+------------------------------+
| Variable_name | Value |
+-------------------------+------------------------------+
| innodb_version | 5.7.23 |
| protocol_version | 10 |
| slave_type_conversions | |
| tls_version | TLSv1,TLSv1.1 |
| version | 5.7.23-log |
| version_comment | MySQL Community Server (GPL) |
| version_compile_machine | x86_64 |
| version_compile_os | Linux |
+-------------------------+------------------------------+
8 rows in set (0.04 sec)
mysql>
This has the default STRICT_TRANS_TABLES mode enabled.
I dont know if this setting is somehow related to the problem.
I havent been able to get access to a server with this setting turned off yet.
Totally agree about you comments regarding updating the database.
It is not my intention to do so. I’ve updated the tables detailed simply
as a mechanism to get some more information about the underlying issue, which seems
to be related to default values in the database.
The created_at column was modified as the application also complained about the lack of a
default value for this column. This is only a test system.
Output from your suggested queries is below:
mysql> select count(*) from properties where is_empty is NULL;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.03 sec)
mysql> select count(*) from internal_properties where is_empty is NULL;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.04 sec)