[rt-devel] Re: Schema Trouble?

[Jesse]

On Thu, Dec 14, 2000 at 03:59:48PM -0600, Eric Miller wrote:
> Thanks, I'm upgrading mysql now..
> The modules weren't very difficult to install, I was just commenting on
> the number used.. 

*nod* Well, it was that or reimplement the functionality. Which would be 
rather, well, not worth my time. There have been cases where I've hacked
together my own functionality similar to that in a CPAN module when the 
module was too heavyweighoroken to cope.

> I had to install HTML::Mason and Apache::Session
> manually tho.. cpan failed to detect the database modules installed and
> I had to point config.pm for the module to GDBM_File..
 
Ah. suck.

> One other question tho, is it possible/very difficult to implement
> date/timestamps as the serial #'s for tickets? Eg. 2000121400001 for the
> 1st ticket on Dec. 14, 2000.. Or a similar datebased serial system.. ??
> Then again, I could just go rooting thru the source.. but i thought i
> would ask you first in case someone has already done this with RT.

Well, internally, RT generates ticket IDs based on your database's 
(or our emulated) serial # type.  Ticket #s are assumed to be 
integers. they don't have to be sequential.  I suppose you could create
a daemon which increments the minimum serial # each midnight..if your
database supports ints that large.  _Alternatively_, RT supports the concept
of a textual alias for each ticket.  It wouldn't be too hard to write a 'Scrip' that, on ticket creation, sets its alias to your custom id scheme.
Then, change your scrip mail actions to default to Ticket Alias rather
than ticket id. (which I may do in the core once I think on it a bit harder)


Jesse
 
> Thanks
> Eric
> 
> Jesse wrote:
> > 
> > Real simple. you need mysql 3.23.
> > installing the modules should not be too hard.
> > 
> > perl bin/testdeps -fix
> > 
> > On Thu, Dec 14, 2000 at 12:40:03PM -0600, Eric Miller wrote:
> > > I'm having trouble with the database schema that comes with the CVS and
> > > latest devel versions of RT. In several places, there are UNIQUE fields
> > > defined, but some also attempt to allow NULL values. If there are two
> > > rows with the field/column set to NULL, it wouldnt be UNIQUE anymore,
> > > would it? Anyway, I get a mysql error when i try to install RT because
> > > it balks on the attempt to create a UNIQUE field that allows NULL.
> > >
> > > CREATE TABLE Links (
> > >   id INTEGER NOT NULL  AUTO_INCREMENT,
> > >   Base varchar(240) NULL  ,
> > >   Target varchar(240) NULL  ,
> > >   Type varchar(20) NOT NULL  ,
> > >   LocalTarget integer NULL  ,
> > >   LocalBase integer NULL  ,
> > >   LastUpdatedBy integer NULL  ,
> > >   LastUpdated DATETIME NULL  ,
> > >   Creator integer NULL  ,
> > >   Created DATETIME NULL  ,
> > >   PRIMARY KEY (id),
> > >   UNIQUE (Base, Target, Type)
> > > )
> > > DBD::mysql::st execute failed: Column 'Base' is used with UNIQUE or
> > > INDEX but is not defined as NOT NULL at tools/initdb line 65, <STDIN>
> > > line 2.
> > > Column 'Base' is used with UNIQUE or INDEX but is not defined as NOT
> > > NULL at tools/initdb line 65, <STDIN> line 2.
> > > Issuing rollback() for database handle being DESTROY'd without explicit
> > > disconnect(), <STDIN> line 2.
> > > make: *** [database] Error 255
> > >
> > > I'm using:
> > > /usr/local/mysql/bin/mysql  Ver 9.38 Distrib 3.22.32, for sun-solaris2.7
> > > (sparc)
> > >
> > > Please let me know if you need more information..
> > >
> > > I had tried to hack the install schema and change the defines to be NOT
> > > NULL for all the columns that I got errors on but then I got an error in
> > > RT when I attempted to add a ticket because the code attempted to put in
> > > a NULL value for the column I had changed to NOT NULL. Also, with this
> > > table in particular (Links), I remember getting an error because the sum
> > > of the lengths of all the unique columns, Base, Target, and Type, is
> > > greater than 256.. ie. 240+240+20 > 256.. This caused another error in
> > > mysql.. Now, maybe I need to change something or upgrade to allow for
> > > unique indexes greater than 256, but it doesnt seem like its ever going
> > > to be logical to allow for NULL values in a UNIQUE data field... ???
> > >
> > > I would appreciate your help greatly..
> > > Thanks,
> > > Eric
> > >
> > > Oh, and do you think you could include more modules? The umpteen-billion
> > > included were just too much fun to install :)
> > >
> > 
> > --
> > jesse reed vincent -- root at eruditorum.org -- jesse at fsck.com
> > 70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90
> > 
> > As I sit here alone looking at green text on a laptop in a mostly bare room listening
> > to loud music wearing all black, I realize that that it is much less cool in real life :)
> >                         --Richard Tibbets
> >
> 

-- 
jesse reed vincent -- root at eruditorum.org -- jesse at fsck.com 
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

I think co-ordinating 1000 prima donnas living all over the world will be as 
easy as herding cats..." -- Andy Tanenbaum on the linux development model, 1992