Sat, 04 Apr 2026 16:31:27 +0000 https://bugs.horde.org/ticket/9223 Kronolith_Tagger: ensureTypes not recognizing existing types A fatal error has occurred SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'calendar' for key 2 Sat, 04 Sep 2010 17:23:32 +0000 https://bugs.horde.org/ticket/9223#t59838 I can't duplicate this. What RDBMS are you using? Have you changed anything related to the database? Can you provide steps to reproduce? Sat, 04 Sep 2010 21:02:54 +0000 https://bugs.horde.org/ticket/9223#t59843 it seems there was an issue with the db_migrate script. after migrating down and up again. everything works fine. thx Sat, 04 Sep 2010 22:42:25 +0000 https://bugs.horde.org/ticket/9223#t59845 No luck, the error is coming again. I will try to investigate Sat, 04 Sep 2010 22:48:23 +0000 https://bugs.horde.org/ticket/9223#t59846 The issue comes from the Content_Types_Manager class, Function ensureTypes. If I change the coding from "if (is_int($type)" to "if (is_int($typeIndex))" everything works fine. My database looks like this: type_id type_name 1 calendar 2 event Sat, 04 Sep 2010 23:06:07 +0000 https://bugs.horde.org/ticket/9223#t59847 > The issue comes from the Content_Types_Manager class, Function > ensureTypes. If I change the coding from "if (is_int($type)" to "if > (is_int($typeIndex))" everything works fine. That code is incorrect and will likely corrupt your content data. You can see what the query on line 69 returns from your DB, and compare it with what you think it should return. Sat, 04 Sep 2010 23:17:48 +0000 https://bugs.horde.org/ticket/9223#t59849 Yes, you're right. The problem is $typeName consists of name/id, but the sql statement is returning id/name. So the unset is not working. I am using Mysql. Any idea? Sat, 04 Sep 2010 23:33:26 +0000 https://bugs.horde.org/ticket/9223#t59850 The coding seems to be even more complex. At the moment I can hardly believe this part was ever working. Can you confirm? Sun, 05 Sep 2010 00:56:02 +0000 https://bugs.horde.org/ticket/9223#t59852 as I stated earlier, I am not seeing any issues. Sun, 05 Sep 2010 01:18:39 +0000 https://bugs.horde.org/ticket/9223#t59853 The db statement is returning an array. I assume this should only be a string? Array ( [0] => calendar ) Warning: Illegal offset type in /horde/content/lib/Types/Manager.php on line 71 Warning: Illegal offset type in unset in /horde/content/lib/Types/Manager.php on line 72 Sun, 05 Sep 2010 10:11:21 +0000 https://bugs.horde.org/ticket/9223#t59855 > The db statement is returning an array. I assume this should only be > a string? No, it should be an array, that's why it's in a foreach loop. That's what selectAssoc() is expected to return. type_id should be the key, and type_name is the value. So.... in the loop, $id is the type_id and $type is type_name. Sun, 05 Sep 2010 14:36:44 +0000 https://bugs.horde.org/ticket/9223#t59859 By the way, can you *please* use a real email address when reporting bugs, devs get multiple bounce notices each time one of your tickets is updated. Sun, 05 Sep 2010 14:43:33 +0000 https://bugs.horde.org/ticket/9223#t59860 >> The db statement is returning an array. I assume this should only be >> a string? > > No, it should be an array, that's why it's in a foreach loop. That's > what selectAssoc() is expected to return. type_id should be the key, > and type_name is the value. So.... in the loop, $id is the type_id > and $type is type_name. Exactly there's the problem in the loop. Here is my debugging: 1. loop: $key: 0 $type: Array ( [calendar] => 1 ) 2. loop: $key: 1 $type: Array ( [event] => 2 ) If I understand everything right, it should be: 1. loop: $key: 1 $type: calendar 2. loop: $key: 2 $type: event Sun, 05 Sep 2010 14:59:03 +0000 https://bugs.horde.org/ticket/9223#t59861 > Exactly there's the problem in the loop. Here is my debugging: > 1. loop: > $key: 0 > $type: Array ( [calendar] => 1 ) > 2. loop: > $key: 1 > $type: Array ( [event] => 2 ) You are getting these values inside the foreach loop that does the db->selectAssoc() call (line 70 or so)? That looks badly broken. What does your table look like? Sun, 05 Sep 2010 15:33:06 +0000 https://bugs.horde.org/ticket/9223#t59866 Here's the export of my table: CREATE TABLE `rampage_types` ( `type_id` int(10) unsigned NOT NULL auto_increment, `type_name` varchar(255) NOT NULL, PRIMARY KEY (`type_id`), UNIQUE KEY `rampage_objects_type_name` (`type_name`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ; INSERT INTO `rampage_types` (`type_id`, `type_name`) VALUES (1, 'calendar'), (2, 'event'); The result of the db-statement is: Array ( [0] => Array ( [1] => calendar ) [1] => Array ( [2] => event ) ) -> $id=0; $type=Array ( [1] => calendar ) -> $id=1; $ype=Array ( [2] => event ) Sun, 05 Sep 2010 19:27:02 +0000 https://bugs.horde.org/ticket/9223#t59868 > The result of the db-statement is: > Array ( [0] => Array ( [1] => calendar ) [1] => Array ( [2] => event ) ) > -> $id=0; $type=Array ( [1] => calendar ) > -> $id=1; $ype=Array ( [2] => event ) Sorry to belabor the point, but this is the output of: var_dump($this->_db->selectAssoc('SELECT type_id, type_name FROM ' . $this->_t('types') . ' WHERE type_name IN ('.implode(',', array_map(array($this->_db, 'quote'), array_keys($typeName))).')')); ? When I dump that, I (correctly) get: array(2) { [1]=> string(8) "calendar" [2]=> string(5) "event" } Sun, 05 Sep 2010 20:08:32 +0000 https://bugs.horde.org/ticket/9223#t59870 >> The result of the db-statement is: >> Array ( [0] => Array ( [1] => calendar ) [1] => Array ( [2] => event ) ) >> -> $id=0; $type=Array ( [1] => calendar ) >> -> $id=1; $ype=Array ( [2] => event ) > > Sorry to belabor the point, but this is the output of: > > var_dump($this->_db->selectAssoc('SELECT type_id, > type_name FROM ' . $this->_t('types') . ' WHERE type_name IN > ('.implode(',', array_map(array($this->_db, 'quote'), > array_keys($typeName))).')')); > > ? > > When I dump that, I (correctly) get: > > > array(2) { [1]=> string(8) "calendar" [2]=> string(5) "event" } Here is the dump I get. I am using mysql array(2) { [0]=> array(1) { [1]=> string(8) "calendar" } [1]=> array(1) { [2]=> string(5) "event" } } Sun, 05 Sep 2010 20:57:04 +0000 https://bugs.horde.org/ticket/9223#t59875 db->selectAssoc is calling db->selectAll. If I compare base and mysql implementation, selectAll is coded differently. Content is using only base at the moment. I guess thats the issue. Mon, 06 Sep 2010 21:35:29 +0000 https://bugs.horde.org/ticket/9223#t59883 It seems it's not only a kronolith/content issue. I have a similiar issue with perms. It seems I am only using base and not the mysql specific db adapter. any ideas? Mon, 06 Sep 2010 22:19:36 +0000 https://bugs.horde.org/ticket/9223#t59885 Do you have pdo and pdo_mysql enabled in PHP? Tue, 07 Sep 2010 00:00:53 +0000 https://bugs.horde.org/ticket/9223#t59888 > Do you have pdo and pdo_mysql enabled in PHP? With the Horde System Test I get the following: PHP Module Capabilities MySQL Support: Yes PDO: Yes Tue, 07 Sep 2010 09:05:03 +0000 https://bugs.horde.org/ticket/9223#t59898 ...sure, but do you have the mysql pod module as well? This is separate from PDO itself, and different then the native mysql support. Tue, 07 Sep 2010 14:30:59 +0000 https://bugs.horde.org/ticket/9223#t59904 In test.php I can see the pdo_mysql extension is activated. I am just wondering because the function list is empty. Is this maybe an issue? Tue, 07 Sep 2010 22:20:30 +0000 https://bugs.horde.org/ticket/9223#t59917 I just tested PDO with this snippet. It was working fine. $dbh = new PDO('mysql:host=localhost;dbname=test','mydbuser','mydbpassword'); Tue, 07 Sep 2010 22:27:52 +0000 https://bugs.horde.org/ticket/9223#t59918 Passing on to Chuck... I can't reproduce and I'm not as intimate with Horde_Db code. Tue, 07 Sep 2010 23:11:28 +0000 https://bugs.horde.org/ticket/9223#t59919 In old versions there was a factory method in Adapter.php for implementing the Horde_Db_ class. Where is this logic done now? Wed, 08 Sep 2010 19:13:41 +0000 https://bugs.horde.org/ticket/9223#t59937 I guess I found the issue. The implementation of the pdo_mysql adapter is incomplete. I changed the coding to switch to normal mysql adapter. Now kronolith and perms are working fine. I assume the mysql-specific coding for selectAll is missing in pdo_mysql. Can you confirm? Wed, 08 Sep 2010 20:14:21 +0000 https://bugs.horde.org/ticket/9223#t59939 > In old versions there was a factory method in Adapter.php for > implementing the Horde_Db_ class. Where is this logic done now? Horde_Core_Factory_Db Wed, 08 Sep 2010 20:22:05 +0000 https://bugs.horde.org/ticket/9223#t59940 > I guess I found the issue. The implementation of the pdo_mysql > adapter is incomplete. No, it looks fine. That's the adapter that I'm using with no issues. Horde_Db_Adapter_Pdo_Mysql extends Horde_Db_Adapter_Pdo_Base, and the implementation in *_Pdo_Base looks fine. Are you sure you are 100% up to date with git and have no local modifications? Wed, 08 Sep 2010 21:05:32 +0000 https://bugs.horde.org/ticket/9223#t59942 what is the result if you dump fetchall results from line 145 of Adapter/Pdo/Base.php? Wed, 08 Sep 2010 21:12:58 +0000 https://bugs.horde.org/ticket/9223#t59945 array(2) { [0]=> array(1) { [1]=> string(8) "calendar" } [1]=> array(1) { [2]=> string(5) "event" } } Wed, 08 Sep 2010 21:44:09 +0000 https://bugs.horde.org/ticket/9223#t59949 Ok. I think I know what' s wrong. What version of PHP are you running? Wed, 08 Sep 2010 23:04:31 +0000 https://bugs.horde.org/ticket/9223#t59951 Changes have been made in Git for this ticket: PDO::FETCH_KEY_PAIR is only available since PHP 5.2.3 Bug: 9223 http://git.horde.org/diff.php/framework/Db/lib/Horde/Db/Adapter/Pdo/Base.php?rt=horde-git&r1=c104a5b3f580a516f34d2c1efe7241a167e280f4&r2=f6c4867ad140073c32b030c0510c31b0aa7d688f Wed, 08 Sep 2010 23:14:21 +0000 https://bugs.horde.org/ticket/9223#t59952 Try now? Wed, 08 Sep 2010 23:14:45 +0000 https://bugs.horde.org/ticket/9223#t59953 I have PHP Version: 5.2.3-1~edh.0. So this coding is not working for me. Thu, 09 Sep 2010 22:20:09 +0000 https://bugs.horde.org/ticket/9223#t59961 Alright, well, since those results are coming directly from PDO, that leaves two possibilities: either your PHP build is broken, or the PHP documentation is incorrect. Can you see what the following outputs on your system? echo constant('PDO::FETCH_KEY_PAIR'); Thu, 09 Sep 2010 23:56:58 +0000 https://bugs.horde.org/ticket/9223#t59966 Also, what does echo PHP_VERSION output? Fri, 10 Sep 2010 00:00:01 +0000 https://bugs.horde.org/ticket/9223#t59967 > Also, what does echo PHP_VERSION output? PHP VERSION: 5.2.3-1~edh.0 PDO::FETCH_KEY_PAIR: 12 I had issues with updating php5 with debian etch. maybe that's the reason? Fri, 10 Sep 2010 06:30:52 +0000 https://bugs.horde.org/ticket/9223#t59968 >> Also, what does echo PHP_VERSION output? > PHP VERSION: 5.2.3-1~edh.0 > PDO::FETCH_KEY_PAIR: 12 Well, this is definitely not a horde bug then. We are passing the correct constant to the correct PDO library call, and getting back the wrong data structure. You can try investigating this further with your distribution's PHP maintainer, or try compiling PHP from source. Fri, 10 Sep 2010 17:03:23 +0000 https://bugs.horde.org/ticket/9223#t59978