[rt-users] Custom Statuses

Schultz, Eric ESchultz at corp.untd.com
Wed Apr 12 14:54:05 EDT 2006


> -----Original Message-----
> From: Joshua Colson [mailto:jcolson at realm.ination.cc] 
> Sent: Wednesday, April 12, 2006 11:33 AM
> To: rt-users at lists.bestpractical.com
> Cc: Schultz, Eric
> Subject: RE: [rt-users] Custom Statuses
> 
> On Wed, 2006-04-12 at 11:17 -0700, Schultz, Eric wrote:
> > I noticed that the link you reference says you can't have a status
> > longer than 10 characters.  Does anyone know why this is?  
> That explains
> > why I got the error it describes for a status of 
> "resolved_notdone".  I
> > thought it may have been the underscore, but I never looked into it.
> 
> Because the field in the database is defined as 'Status VARCHAR(10)'.
> Which means that the database will not accept a value of Status longer
> than 10 characters.
> 
> HTH
> 
> Joshua Colson

Oh, DUH :-)  Guess I could have checked this myself.  In that case,
issue this command to increase the upper limit on Status in MySQL:

ALTER TABLE Tickets CHANGE Status Status varchar(32);

Yes, "Status" should be there twice.  I chose 32 because I like powers
of 2 in my schema :-)  Of course, the smarter thing would be to make all
the columns char rather than varchar so you don't have to worry about
irregular length records, and don't make the fixed-length field much
larger than you need.  If you can get by with 16 or 24 above, then do
it.  Once they are all fixed length, you get speedier queries.  Other
changes I would make include making Disabled and all of the Priority
columns a tinyint (this puts a hard limit of 255 for the largest value,
and uses half as much storage), and using timestamp rather than datetime
for the date fields (since we don't extract the time separately and the
former uses half the storage).  When you get into the realm of 100,000
tickets, you can save a few megabytes in doing this.



More information about the rt-users mailing list