Blank Comment

Hi
If I open a existing ticket and click on Comment, then click on Home
without doing anything on the comment screen, RT saves a blank Comment.

Does any one else have this problem? I haven’t had this problem with
3.0.11. I’m not sure if it is a scrip yet. i checked mine, but couldn’t
see how it would be able to do this.

Leon

If I open a existing ticket and click on Comment, then click on Home
without doing anything on the comment screen, RT saves a blank Comment.

Does any one else have this problem? I haven’t had this problem with
3.0.11. I’m not sure if it is a scrip yet. i checked mine, but couldn’t
see how it would be able to do this.

I bet you’re using MySQL and your tables are MyISAM and not InnoDB.

In RT 3.2, when you load the update page, it looks like RT creates an
empty comment or reply and then rolls back the transaction. Since
MyISAM tables don’t support transactions, the blank comment/reply stays.

I didn’t trace this through in the code so I don’t know where it happens
– I figured it out my observing my MySQL query log when I noticed the
same thing on a test RT instance where I had set it up with MyISAM
tables.

–Bret

I bet you’re using MySQL and your tables are MyISAM and not InnoDB.
That’d be my guess, too.

I didn’t trace this through in the code so I don’t know where it happens
It happens when the “this message will be sent to” section is generated;
the most foolproof method is, as you noted, to fake a comment, find out
what happened, then roll it back.
The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

  • Alex

Networking – one letter away from not working

The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

I don’t know if you care, but I noticed when installing RT 3.2.0 that
the stanza that creates the “sessions” table in schema.mysql doesn’t
have “TYPE=InnoDB;” at the end, but all the other CREATE TABLEs do have
it.

At first I wasn’t sure why that one table way MyISAM and the rest were
InnoDB – this was before I switched my MySQL configuration to have
InnoDB as the default table type.

Then again, maybe RT’s use of that table doesn’t require InnoDB
functionality. Seems like it would be nice to have the tables all of
the same type though.

–Bret

The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

I don’t know if you care, but I noticed when installing RT 3.2.0 that
the stanza that creates the “sessions” table in schema.mysql doesn’t
have “TYPE=InnoDB;” at the end, but all the other CREATE TABLEs do have
it.

The sessions table is really just there for Apache::Session. It doesn’t
need to be innodb.

Thanks,

I found this link :
http://manuals.thexdershome.com/mysql-4.0/manual_Table_types.html
To the MySQL manual. It states that i should be able to do a {… use
|ALTER TABLE … TYPE=INNODB …}

Will this be sufficient on each table in my RT database ?

I really can’t afford to lose my tickets, but i also need to upgrade to
the next version as soon as it becomes available.

|Leon

Bret Martin wrote:>On Tue, 13 Jul 2004 17:08:47 EDT Alex Vandiver wrote:

The solution is to use a MySQL server that supports InnoDB tables.
Starting with RT 3.2.1, trying to install RT with a MySQL build that
doesn’t support InnoDB tables will give an error.

I don’t know if you care, but I noticed when installing RT 3.2.0 that
the stanza that creates the “sessions” table in schema.mysql doesn’t
have “TYPE=InnoDB;” at the end, but all the other CREATE TABLEs do have
it.

At first I wasn’t sure why that one table way MyISAM and the rest were
InnoDB – this was before I switched my MySQL configuration to have
InnoDB as the default table type.

Then again, maybe RT’s use of that table doesn’t require InnoDB
functionality. Seems like it would be nice to have the tables all of
the same type though.

–Bret


The rt-users Archives

Be sure to check out the RT wiki at http://wiki.bestpractical.com

I have done a dump of my database.
Then I did an “Alter table … Type = InnoDB;” for each table in my
database.
i did a commit.
I restarted the MySQL.
I still have the same problem as below.
I then proceeded to do an update of RT3.2.1 ( which was successful)
And I still have the problem.

Is there some way I can check if my MySQL does have the correct support
for InnoDB tables ?
Is there something that I missed ?

Regards
Leon

Leon wrote:

Is there some way I can check if my MySQL does have the correct support
for InnoDB tables ?
mysql> show variables like ‘have_innodb’;
| Variable_name | Value |
| have_innodb | YES |
1 row in set (0.00 sec)

If it says NO, MySQL doesn’t have InnoDB support compiled in at all.
If it says DISABLED, support is compiled in but not enabled in the
configuration; this is fixable by removing the ‘skip-innodb’ line from
your my.cnf file and restarting MySQL.

  • Alex

Networking – one letter away from not working

Thanks I will have a look at this tomorrow morning at the office.

Alex Vandiver wrote:>On Fri, 2004-07-16 at 15:13, Leon wrote:

Is there some way I can check if my MySQL does have the correct support
for InnoDB tables ?

mysql> show variables like ‘have_innodb’;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| have_innodb | YES |
±--------------±------+
1 row in set (0.00 sec)

If it says NO, MySQL doesn’t have InnoDB support compiled in at all.
If it says DISABLED, support is compiled in but not enabled in the
configuration; this is fixable by removing the ‘skip-innodb’ line from
your my.cnf file and restarting MySQL.

  • Alex