6.0.0-git
2019-03-23

[#9223] Kronolith_Tagger: ensureTypes not recognizing existing types
Summary Kronolith_Tagger: ensureTypes not recognizing existing types
Queue Kronolith
Queue Version Git master
Type Bug
State Not A Bug
Priority 1. Low
Owners mrubinsk (at) horde (dot) org
Requester test (at) horde (dot) org
Created 2010-09-04 (3122 days ago)
Due
Updated 2010-09-10 (3116 days ago)
Assigned 2010-09-04 (3122 days ago)
Resolved 2010-09-10 (3116 days ago)
Milestone
Patch No

History
2010-09-10 17:04:09 Michael Rubinsky Summary ⇒ Kronolith_Tagger: ensureTypes not recognizing existing types
 
2010-09-10 17:03:23 Michael Rubinsky Comment #39
State ⇒ Not A Bug
Reply to this comment
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.


2010-09-10 06:30:52 hordetest (at) trash-mail (dot) com Comment #38 Reply to this comment
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?
2010-09-10 00:00:01 Michael Rubinsky Comment #37 Reply to this comment
Also, what does echo PHP_VERSION output?
2010-09-09 23:56:58 Michael Rubinsky Comment #36 Reply to this comment
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');


2010-09-09 22:20:09 hordetest (at) trash-mail (dot) com Comment #35 Reply to this comment
I have PHP Version: 5.2.3-1~edh.0. So this coding is not working for me.
2010-09-08 23:14:45 Michael Rubinsky Comment #34
Assigned to Michael Rubinsky
Taken from Chuck Hagenbuch
Reply to this comment
Try now?
2010-09-08 23:04:31 Michael Rubinsky Comment #32 Reply to this comment
Ok. I think I know what' s wrong.  What version of PHP are you running?
2010-09-08 21:44:09 hordetest (at) trash-mail (dot) com Comment #31 Reply to this comment
array(2) { [0]=>  array(1) { [1]=>  string(8) "calendar" } [1]=>   
array(1) { [2]=>  string(5) "event" } }
2010-09-08 21:12:58 Michael Rubinsky Comment #30 Reply to this comment
what is the result if you dump fetchall results from line 145 of 
Adapter/Pdo/Base.php?
2010-09-08 21:05:32 Michael Rubinsky Comment #29 Reply to this comment
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?

2010-09-08 20:22:05 Michael Rubinsky Comment #28 Reply to this comment
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
2010-09-08 20:14:21 hordetest (at) trash-mail (dot) com Comment #27 Reply to this comment
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?
2010-09-08 19:13:41 hordetest (at) trash-mail (dot) com Comment #26 Reply to this comment
In old versions there was a factory method in Adapter.php for 
implementing the Horde_Db_ class. Where is this logic done now?
2010-09-07 23:11:28 Michael Rubinsky Comment #25
Assigned to Chuck Hagenbuch
Summary ⇒ Kronolith_Tagger: ensureTypes not recognizing existing typesc
Reply to this comment
Passing on to Chuck... I can't reproduce and I'm not as intimate with 
Horde_Db code.
2010-09-07 22:27:52 hordetest (at) trash-mail (dot) coom Comment #24 Reply to this comment
I just tested PDO with this snippet. It was working fine.
$dbh = new PDO('mysql:host=localhost;dbname=test','mydbuser','mydbpassword');

2010-09-07 22:20:30 hordetest (at) trash-mail (dot) com Comment #23 Reply to this comment
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?
2010-09-07 14:30:59 Michael Rubinsky Comment #22 Reply to this comment
...sure, but do you have the mysql pod module as well? This is 
separate from PDO itself, and different then the native mysql support.
2010-09-07 09:05:03 hordetest (at) trash-mail (dot) com Comment #21 Reply to this comment
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
2010-09-07 00:00:53 Michael Rubinsky Comment #20 Reply to this comment
Do you have pdo and pdo_mysql enabled in PHP?
2010-09-06 22:19:36 hordetest (at) trash-mail (dot) com Comment #19 Reply to this comment
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?
2010-09-06 21:35:29 hordetest (at) trash-mail (dot) com Comment #18 Reply to this comment
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.
2010-09-05 20:57:04 hordetest (at) trash-mail (dot) com Comment #17 Reply to this comment

[Show Quoted Text - 18 lines]
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" } }
2010-09-05 20:08:32 Michael Rubinsky Comment #16 Reply to this comment
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" }
2010-09-05 19:27:02 hordetest (at) trash-mail (dot) com Comment #15 Reply to this comment
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 )
2010-09-05 15:33:06 Michael Rubinsky Comment #14 Reply to this comment
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?
2010-09-05 14:59:03 testhorde (at) trash-mail (dot) com Comment #13 Reply to this comment
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
2010-09-05 14:43:33 Michael Rubinsky Comment #12 Reply to this comment
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.
2010-09-05 14:36:44 Michael Rubinsky Comment #11 Reply to this comment
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.
2010-09-05 10:11:21 test (at) horde (dot) org Comment #10 Reply to this comment
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
2010-09-05 01:18:39 Michael Rubinsky Comment #9 Reply to this comment
as I stated earlier, I am not seeing any issues.
2010-09-05 00:56:02 test (at) horde (dot) org Comment #8 Reply to this comment
The coding seems to be even more complex. At the moment I can hardly 
believe this part was ever working. Can you confirm?
2010-09-04 23:33:26 test (at) horde (dot) org Comment #7 Reply to this comment
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?
2010-09-04 23:17:48 Michael Rubinsky Comment #6 Reply to this comment
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.
2010-09-04 23:06:07 test (at) horde (dot) org Comment #5 Reply to this comment
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

2010-09-04 22:48:23 test (at) horde (dot) org Comment #4 Reply to this comment
No luck, the error is coming again. I will try to investigate
2010-09-04 22:42:25 test (at) horde (dot) org Comment #3 Reply to this comment
it seems there was an issue with the db_migrate script. after 
migrating down and up again. everything works fine. thx
2010-09-04 21:02:54 Michael Rubinsky Comment #2
State ⇒ Feedback
Reply to this comment
I can't duplicate this. What RDBMS are you using? Have you changed 
anything related to the database? Can you provide steps to reproduce?
2010-09-04 17:23:32 test (at) horde (dot) org Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Kronolith_Tagger: ensureTypes not recognizing existing types
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
A fatal error has occurred
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
'calendar' for key 2

Saved Queries