You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Exporting data even without any parameters breaks sql dump. It shows the table structure, but when the data should be returned, process stops with no errors.
KEY `user_field__created` (`created`),
KEY `user_field__access` (`access`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='The data table for user entities.';
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `users_field_data`
--
LOCK TABLES `users_field_data` WRITE;
/*!40000 ALTER TABLE `users_field_data` DISABLE KEYS */;
SET autocommit=0;
[error] Database dump failed
[error] Unable to dump database. Rerun with --debug to see any error message.
And it's because ifsnop/mysqldump-php#141 was never accepted and so the new solution using hooks was not implemented. Also, I have a situation where I can't edit project's json file to add patches and just using composer require does not apply patches (137 to be specific).
My proposal is adding a check on $this->gdprExpressions[$tableName] before invoking $this->tableColumnTypes()[$tableName]. See PR here: #27
The text was updated successfully, but these errors were encountered:
that doesn't fix the "null pointer". A solution could be a hack using reflection in the constructor to get access to parents private tableColumnTypes field via a getter in the subclass.
Exporting data even without any parameters breaks sql dump. It shows the table structure, but when the data should be returned, process stops with no errors.
And adding a
--debug
does not reveal anything.What I found out, it breaks here
And it's because ifsnop/mysqldump-php#141 was never accepted and so the new solution using hooks was not implemented. Also, I have a situation where I can't edit project's json file to add patches and just using composer require does not apply patches (137 to be specific).
My proposal is adding a check on
$this->gdprExpressions[$tableName]
before invoking$this->tableColumnTypes()[$tableName]
. See PR here: #27The text was updated successfully, but these errors were encountered: