rampage table index error

the bug related with #7948 after we created the tables th

Mon, 09 Feb 2009 23:27:19 +0000

the bug related with #7948 after we created the tables the 7948 errors gone away. but when i add the 2. event to the calendar i recive the following error: Fatal error: Uncaught exception 'Horde_Db_Exception' with message 'QUERY FAILED: Duplicate entry '2' for key 2 INSERT INTO `rampage_objects` (object_name, type_id) VALUES ('20090209234236.14139w80iit4xxss@195.70.38.187', 2)' in /usr/share/php/Horde/Db/Adapter/Mysqli.php:299 Stack trace: #0 /usr/share/php/Horde/Db/Adapter/Mysqli.php(324): Horde_Db_Adapter_Mysqli->execute('INSERT INTO `ra...', NULL, NULL) #1 /usr/share/horde/content/lib/Objects/Manager.php(122): Horde_Db_Adapter_Mysqli->insert('INSERT INTO `ra...') #2 /usr/share/horde/content/lib/Tagger.php(703): Content_Objects_Manager->ensureObjects('20090209234236....', 2) #3 /usr/share/horde/content/lib/Tagger.php(186): Content_Tagger->_ensureObject(Array) #4 /usr/share/horde/kronolith/lib/Tagger.php(122): Content_Tagger->removeTagFromObject(Array, Array) #5 /usr/share/horde/kronolith/lib/Tagger.php(160): Kronolith_Tagger->untag('20090209234236....', Array, 'event') #6 /usr/share/horde/kronolith/lib/Driver/sql.php(516): Kronolith_Tagger->replaceTags('20090209234236.... in /usr/share/php/Horde/Db/Adapter/Mysqli.php on line 299 the xml part abut this index: rampage_objects_type_object_name true type_id ascending object_name ascending our solution is simply: drop the unique index and it's work perfectly.

Please pick the correct version.

Mon, 09 Feb 2009 23:31:31 +0000

Please pick the correct version.

> Please pick the correct version. sorry. my mistake. that'

Mon, 09 Feb 2009 23:40:15 +0000

> Please pick the correct version. sorry. my mistake. that's end of the list, and i do not notice. i will keep my eyes on that!

Can you please try this with a fresh set of rampage tables a

Tue, 10 Feb 2009 00:19:21 +0000

Can you please try this with a fresh set of rampage tables and post the *exact* steps that you took to produce this error? If I understand your error correctly, after you removed the 'unique' flag and ran it again, you have two entries for the same event in the rampage_objects table (two entries where object_name and type_id are equal)? Not really sure how that would happen as the object_name is a UID...

the type id is the same: +-----------+---------------------

Tue, 10 Feb 2009 00:34:03 +0000

the type id is the same: +-----------+-----------------------------------------------+---------+ | object_id | object_name | type_id | +-----------+-----------------------------------------------+---------+ | 1 | 20090209224113.11603rqwzfxp9iih@myip | 2 | | 2 | 20090209234236.14139w80iit4xxss@myip | 2 | +-----------+-----------------------------------------------+---------+ I simply drop the index: alter table rampage_objects drop index rampage_objects_type_object_name; the creation method was not very professional :) i create the SQL command by hand form the xml becasue this looked like the fastest way for me. CREATE TABLE `rampage_objects` ( `object_id` int(10) unsigned NOT NULL auto_increment, `object_name` varchar(255) NOT NULL, `type_id` int(10) unsigned NOT NULL, PRIMARY KEY (`object_id`), UNIQUE KEY `rampage_objects_type_object_name` (`type_id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

sigh That is NOT the correct SQL statement.

Tue, 10 Feb 2009 00:38:38 +0000

*sigh* That is NOT the correct SQL statement.

> sigh > > That is NOT the correct SQL statement. And

Tue, 10 Feb 2009 22:22:26 +0000

> *sigh* > > That is NOT the correct SQL statement. And which one is incorrect? The SQL part of us, or the xml file? Wouldn't be more simple an sql script like upgrade and install scripts?

> And which one is incorrect? The SQL part of us, or the xml

Wed, 11 Feb 2009 01:53:59 +0000

> And which one is incorrect? The SQL part of us, or the xml file? What is incorrect is your interpretation of the XML schema file. You turned a two column unique index into a single column unique index. > Wouldn't be more simple an sql script like upgrade and install scripts? No, it wouldn't. You should use the scripts located in framework/admintools to create the tables from the schema files. If you need further assistance, please ask on the appropriate mailing list.