Schema Trouble?

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

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,
line 2.
Column ‘Base’ is used with UNIQUE or INDEX but is not defined as NOT
NULL at tools/initdb line 65, line 2.
Issuing rollback() for database handle being DESTROY’d without explicit
disconnect(), 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 :slight_smile:


jesse reed vincent – root@eruditorum.orgjesse@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 :slight_smile:
–Richard Tibbets

jesse reed vincent – root@eruditorum.orgjesse@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