On Thu, 2011-06-23 at 01:53 -0700, Aris Feryanto wrote:
----- Original Message -----
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
Hi Marc,
----- Original Message -----
From: Marc Delisle marc@infomarc.info
From current master, when browsing a table:
Warning in ./libraries/RecentTable.class.php#190 array_unshift() expects parameter 1 to be array, null given
Backtrace
./libraries/RecentTable.class.php#190: array_unshift( NULL, string sakila.actor, ) ./libraries/header.inc.php#22: PMA_RecentTable->add( string sakila, string actor, ) ./libraries/header.inc.php#171: PMA_addRecentTable( string sakila, string actor, ) ./libraries/tbl_links.inc.php#40: require_once(./libraries/header.inc.php) ./sql.php#881: require(./libraries/tbl_links.inc.php)
Odd. It shouldn't be NULL because it is always initialized when PMA_RecentTable class is being constructed. And I can't reproduce this warning. Is this warning found in demo server?
No but possibly, warnings and notices are turned off on the demo server.
On your development machine you should use this line in config.inc.php: $cfg['Error_Handler']['display'] = true;
Hi Marc,
I keep looking for the warning while developing the show/hide column feature, but I still cannot see it until now. Please let me know about your steps to reproduce it.
-- Aris Feryanto
I saw some similar notices some time ago and afterwards the recent tables feature stopped working completely. Today I dumped the pma_recent table and found this:
##### SNIP ##### -- -- Table structure for table `pma_recent` -- CREATE TABLE IF NOT EXISTS `pma_recent` ( `username` varchar(64) COLLATE utf8_bin NOT NULL, `tables` blob NOT NULL, PRIMARY KEY (`username`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin; -- -- Dumping data for table `pma_recent` -- INSERT INTO `pma_recent` (`username`, `tables`) VALUES ('root', 0x6e756c6c); ##### SNIP #####
Of course, if you UNHEX 0x6e756c6c, you get 'null'. No idea how that value got there, but after deleting that row, the feature started to work as expected again.
BTW, I'm not sure why you are storing all the table names in one row. For me it would make more sense to remove the PK constraint from the `username` column and replace it with a non-unique index. After that you can store each user/table combination on a new row, which would make fetching easier and would probably avoid problems like the one I ended up with. Feel free to ignore this or take it on board.
Rouslan