Mantis Bug Tracker
 

View Issue Details Jump to Notes ] Wiki ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008704mantisbtupgradepublic2008-01-03 21:542008-07-31 17:40
Reporterdjcarr 
Assigned Togiallu 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformWindowsOSXPOS VersionSP2
Product Version1.1.0 
Target VersionFixed in Version 
Summary0008704: 1.0.1 to 1.1.0 : default value errors
DescriptionApache 2.2.6, PHP 5.2.5, MySQL 5.0.18

Installed 1.1.0 Final to a new directory, pointed it at a mysqldump'd 1.0.1 db, and went to /admin to upgrade. All lights green during upgrade, and also during check.php after.

Login and View Issues works. But Issue View and Report Issue among other actions report 'Field 'xxx' doesn't have a default value for the query' errors (see Additional Info).
Additional InformationIssue View fails when displaying history:

Database query failed. Error received from database was #1364: Field 'id' doesn't have a default value for the query: INSERT INTO mantis_tokens_table
( type, value, timestamp, expiry, owner )
VALUES ( '3', '12924', '2008-01-04 00:51:26', '2008-01-05 00:51:26', '18' )

Report Issue also fails:

Database query failed. Error received from database was #1364: Field 'id' doesn't have a default value for the query: INSERT INTO mantis_bug_text_table
( description, steps_to_reproduce, additional_information )
VALUES
( 'asdfasdf', '',
'asdf' )

Checking the mysqldump for the 1.0.1 db:

CREATE TABLE `mantis_tokens_table` (
  `id` int(11) NOT NULL,
  `owner` int(11) NOT NULL default '0',
  `type` int(11) NOT NULL default '0',
  `timestamp` datetime NOT NULL default '0000-00-00 00:00:00',
  `expiry` datetime NOT NULL default '0000-00-00 00:00:00',
  `value` text NOT NULL,
  PRIMARY KEY (`id`)
);

CREATE TABLE `mantis_bug_text_table` (
  `id` int(7) unsigned NOT NULL,
  `description` text NOT NULL,
  `steps_to_reproduce` text NOT NULL,
  `additional_information` text NOT NULL,
  PRIMARY KEY (`id`)
);

And finally checking the 1.1.0 tables, post-upgrade:

CREATE TABLE `testmantis`.`mantis_bug_text_table` (
  `id` int(7) unsigned NOT NULL,
  `description` text NOT NULL,
  `steps_to_reproduce` text NOT NULL,
  `additional_information` text NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

REATE TABLE `testmantis`.`mantis_tokens_table` (
  `id` int(11) NOT NULL,
  `owner` int(11) NOT NULL default '0',
  `type` int(11) NOT NULL default '0',
  `timestamp` datetime NOT NULL default '0000-00-00 00:00:00',
  `expiry` datetime NOT NULL default '0000-00-00 00:00:00',
  `value` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_typeowner` (`type`,`owner`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

It appears that Mantis is expecting a default value on these tables, but their fields haven't been specified to use defaults, either in 1.0.1 or 1.1.0.
Tagsverify
Attached Filestxt file icon mantis_upgrade_sql.txt [^] (19,662 bytes) 2008-01-03 22:12 [Show Content]

- Relationships

-  Notes
User avatar (0016543)
djcarr (reporter)
2008-01-03 23:42

The mysqldump command used was:

mysqldump --host=xxx --user=xxx --password=xxx mantisdb --hex-blob --skip-opt --result-file=outputfile.sql
User avatar (0016546)
giallu (developer)
2008-01-04 03:14

Well. the pre and post 1.1 schema looks identical.

Your error "1364: Field 'id' doesn't have a default value" looks suspicious because the id is an auto increment field so it should be added automatically on INSERTs.

All in all, I think it's a problem with your dump/restore (but I can't say where is the problem for sure).

Would you retry the dump omitting "--hex-blob --skip-opt" please? I'm asking this because those are the only options I never used ;)
User avatar (0016557)
thraxisp (manager)
2008-01-05 20:18

I retested this on a fresh database. The "--skip-opt' seems to lose the autoincrement status on all of the tables. Without it, the table dump looks good.

Is it possible that the table was created on one machine and restored on another using the dump?
User avatar (0016567)
djcarr (reporter)
2008-01-07 01:28

Hi... I investigated the mysqldump as well and found the same cause. To confirm, the fault is not with Mantis.

After more investigation I've come up with a set of good guidelines for dumping and importing fairly large mantis databases. I'll post them here in case they can help someone else.

1. In MySQL Server's my.ini set the following. This allows file attachments greater than 1MB to be imported back in.

  [mysqld]
  max_allowed_packet=16M

2. Dump the file attachments table alone in hex format.

mysqldump --host=*** --user=*** --password=*** --hex-blob --skip-extended-insert --result-file=mantisdb_files.sql mantisdb mantis_bug_file_table

Why? Because this one table can get very big and MySQL Server cannot reimport scripts more than about 50MB. So you can then split this table dump into multiple smaller files if needed.

3. Dump the remainder of the database. These options ensure one line per row, again for ease of reading and splitting the dump if needed.

mysqldump --host=*** --user=*** --password=*** --skip-extended-insert --ignore-table=mantisdb.mantis_bug_file_table --result-file=mantisdb.sql mantisdb

5. Import the files in sequence into the NEW database:

mysql --host=*** --user=*** --password=*** newmantisdb < mantisdb_files.sql

mysql --host=*** --user=*** --password=*** newmantisdb < mantisdb.sql

6. Do NOT use the MySQL Query Browser GUI to import - use the command line as above. The Query Browser chokes badly on the many '/ escapings that mysqldump places in the bug text and descriptions.

Anyway hope that helps someone. You may want to close the issue ... thanks!
User avatar (0016571)
giallu (developer)
2008-01-07 06:41

Ok. closing.

I think your procedure could be helpful to other users; it would be nice if you can add it to the wiki, probably in the HOWTO section
User avatar (0016574)
thraxisp (manager)
2008-01-07 08:16

I added the notes to the wiki in http://www.mantisbt.org/wiki/doku.php/mantisbt:db_dump_restore [^]

- Issue History
Date Modified Username Field Change
2008-01-03 21:54 djcarr New Issue
2008-01-03 22:12 djcarr File Added: mantis_upgrade_sql.txt
2008-01-03 23:42 djcarr Note Added: 0016543
2008-01-04 03:14 giallu Note Added: 0016546
2008-01-05 12:34 giallu Status new => feedback
2008-01-05 20:18 thraxisp Note Added: 0016557
2008-01-07 01:28 djcarr Note Added: 0016567
2008-01-07 02:27 seiji Issue Monitored: seiji
2008-01-07 06:41 giallu Status feedback => resolved
2008-01-07 06:41 giallu Resolution open => no change required
2008-01-07 06:41 giallu Assigned To => giallu
2008-01-07 06:41 giallu Note Added: 0016571
2008-01-07 07:00 demo1 Tag Attached: verify
2008-01-07 08:16 thraxisp Note Added: 0016574
2008-07-31 17:40 giallu Status @0@ => closed


MantisBT 1.2.2 git master-1.2.x[^]
Copyright © 2000 - 2010 MantisBT Group
Time: 0.2440 seconds.
memory usage: 1,980 KB
Powered by Mantis Bugtracker