Hi All,
I just nabbed the latest source from SVN and tried to update my copy of Action Streams. However, the upgrade process produced this:
Upgrading table for as_ua_cache records…
* Upgrading table for `as_ua_cache` records...
Error during upgrade: failed to execute statement CREATE INDEX mt_as_ua_cache_url_type ON mt_as_ua_cache (as_ua_cache_url,as_ua_cache_action_type): Specified key was too long; max key length is 1000 bytes at lib/MT/Upgrade.pm line 2595.
I had v 1 (schema v. 9) and was trying to upgrade to v 2 (schema v. 15).
Any thoughts?
—
Regards,
Travis Spencer
Reported on Movable Type 4.2
Here's what I had to do to work around the problem. Someone who knows MySQL will have to explain why this works, if I should back these changes out, and how:
--- ActionStreams/Event.pm~ 2008-12-07 21:15:30.000000000 -0800
+++ ActionStreams/Event.pm 2008-12-07 22:19:26.000000000 -0800
@@ -15,7 +15,7 @@
__PACKAGE__->install_properties({
column_defs => {
id => 'integer not null auto_increment',
- identifier => 'string(200)',
+ identifier => 'string(100)',
author_id => 'integer not null',
visible => 'integer not null',
},
--- ActionStreams/UserAgent/Cache.pm~ 2008-12-07 21:15:30.000000000 -0800
+++ ActionStreams/UserAgent/Cache.pm 2008-12-07 22:19:32.000000000 -0800
@@ -5,10 +5,10 @@
__PACKAGE__->install_properties({
column_defs => {
id => 'integer not null auto_increment',
- url => 'string(255) not null',
- etag => 'string(255)',
- last_modified => 'string(255)',
- action_type => 'string(255) not null',
+ url => 'string(100) not null',
+ etag => 'string(100)',
+ last_modified => 'string(100)',
+ action_type => 'string(100) not null',
},
indexes => {
url_type => { columns => [ 'url', 'action_type' ] },
More info about this issue: http://bugs.mysql.com/bug.php?id=4541.
Here's the skinny on my install of MySQL:
Server version: 5.0.67-log MySQL Community Server (GPL)
I'm not sure if it's using Latin, UTF-8, or if that even matters or makes sense. If someone needs the info and knows how to find this out, post the steps here. I'll check and let you know.
HTH!
--
Regards,
Travis Spencer
Hello Again,
After making the changes above, the upgrade "completes." However, I didn't realize before making the last post that clicking the return to movable type button shown after the upgrade process finishes causes it to start again. It goes in this loop infinitely. When I check the database, sure enough, the schema version for the Action Streams plugin was still 9 :-(
How do I fix this?
--
Regards,
Travis Spencer
You really shouldn't be using SVN here unless you are capable of fixing your own bugs because SVN is intended primarily for developers, not end users. I don't mean to be flippant about your troubles here, but it's just not a good idea for you to be using SVN unless you are comfortable debugging Perl and SQL code.
Mike,
I posted a unified diff, man! I'm a developer too, I'm just a little stuck because I don't know MT as good as you (yet!). Besides, SVN is the only place to get AS these days: http://forums.movabletype.org/2008/11/where-to-download-action-streams-plugin.html#comment-14807.
Rather than get all in my face, why not try to help me out? I'm trying to use this stuff and reporting the problems that I'm having in doing so. I guess I could just get frustrated and switch blogging platforms; but I'm not doing that. I trying to figure this out and making the community aware of the difficulties I'm running into. Geeze, man.
Sorry. I was trying to be civil there (say I do acknowledge that you have a genuine problem there).
That said, I took the liberty of contacting the developer who maintains Action Streams and he fixed the link for you:
http://plugins.movabletype.org/action-streams/
See, I'm not a total jackass :)
The reason I didn't think you were a developer was that I've met a number of people who can handle diffs who aren't developers.
Alright, now, I think this is the problem. If you ran into this problem, your server is probably forcing you to use utf8. I have a very similar environment at my host, but the latest SVN build installed just fine for me because, for whatever reason, my installation of Movable Type is using latin/swedish collation instead of utf8.
If you that patch works for you, it'll be because it gets you in under MySQL's absurdly small index size of 1000 bytes. 530 characters for the index in ASCII is one thing (at 530 bytes), but that becomes 1545 bytes in UTF8... so obviously that's a real issue right there....
Why don't you fire up phpMyAdmin or a similar tool and see what sort of character set your tables are using?
Hi Mike,
I checked out phpMyAdmin as you suggested, and found that the MySQL charset is UTF-8 Unicode (utf8) and the MySQL connection collate is utf8-unicode-ci. When I look at the collation of the different tables, some are latin1-swedish-ci and others are utf8-general-ci. (I've altered and moved this DB around over a number of years.)
When I read about the index size on the site I previously posted, I figured that ratcheting down the column size would fix things. It did allow me to complete the upgrade. However, now it is causing the infinite upgrade loop. Do you have any idea why the component's schema version (PluginSchemaVersion actionstreams in the mt-config database table) isn't be updated during the "successful" upgrade process? I looked through upgrade* code in the ActionStream's Plugin.pm. However, I'm not familiar enough w/ MT's upgrade framework to figure out how to diagnose the problem.
I can't set DebugMode to 4 to see the SQL statements that are being executed ATM because my version of DBI is too old and doesn't support the profiler's as_text function. I'm having some trouble upgrading it, but, once I have, I'll post the traces here if they're insightful.
In the meantime, do you or anyone else in the community have any suggestions that would help me fix this problem? I would really appreciate it.
TIA!
--
Regards,
Travis Spencer
Hello Again,
I used phpMyAdmin to change the collation of the tables mt-profileevent and mt-as-ua-cache from utf8-general-ci to ascii-bin (which is available on the Operations tab of that program's UI). I then backed out the patch from my second post, causing the columns to be 255 characters again. Then, accessing the blog triggered the upgrade process. It ran successfully this time, but the the upgrade procedure continues to loop infinitely.
Here is the output of the warning and log messages (which I was able to get this time because I got my copy of DBI upgraded):
http://travisspencer.com/tmp/upgrade.log
I'm honing in on the problem. Thoughts? Ideas? Suggestions?
--
Regards,
Travis Spencer
Look in config.yaml for the upgrade functions. It very well may be crapping out in one of those. You can also ping Mark Paschal, the developer, to see if he has any suggestions.
Hi All,
Notably absent from that log is any UPDATE statement. I would have expected to see something like this:
UPDATE mt_config SET config_data = '
...
PluginSchemaVersion actionstreams=15
...
' WHERE config_id = 1;
I set "PluginSchemaVersion actionstreams=15" in that cell of the database, manually. (I know. I'm swimming w/ the sharks.) Unsurprisingly, after that, the infinite upgrade loop stopped. However, I've run into two more issues after that:
1. When I add a new service/profile, the service is shown twice in the UI. I've dumped the binary blob in mt-author-meta.author-meta-vblob. Sure enough, the new service-related stuff is in there twice.
2. When I selected to manage my user profile, the navigation sidebar shows the Action Stream and Other Profiles link *twice* (see http://travisspencer.com/tmp/ActionStreamNavigationProblem.GIF).
Any thoughts, ideas, suggestions?
--
Regards,
Travis Spencer
Is it possible that you have two copies of the plugin installed? I'm not trying to insult your intelligence here, but I had a similar thing happen when I wrote two plugins that modified the HTML of the entry editor in the same location. In that case, I knew why it was behaving like that, but in my (limited) experience with CMS-modifying plugins this is the most likely culprit for something like this.
Hi Mike,
Thanks for sticking w/ me on this one. I pinged Mark, but he must be heads down writing this stuff ATM ;-)
Before I checked out the latest code from subversion, I renamed the original ActionStreams directory under the plugins directory to ActionStreams.orig. Ya, not a good idea because then, as you keenly pointed out, you'll have two copies running. The funny thing was that the in the System Plugin Settings, only v. 1.0 was listed. Once I disabled it, ActionStreams.orig v 1.0 and ActionsStreams 2.0 showed up. Deleting this directory fixed the double listing in the navigation.
I would feel fine w/ things now if it weren't for the fact that I had to manually update the database to fix that endless upgrade loop. I'll continue to use it, svn up it, and see if any more problems arise.
--
Thanks Again,
Travis Spencer
Hi All,
After disable the ActionStream.orig plugin that slipped in and removing the associated directory, I set the plugin's schema version back to the 9 (which is what it was w/ v. 1 of the plugin). I then ran the upgrade again. Guess what? No infinite upgrade loop!
Aside from the issue w/ collate, I think the presence of this original directory was the source of my troubles.
Thanks again, Mike, for helping me get to the bottom of this. I owe you one.
--
Regards,
Travis Spencer