DataError: (1264, "Out of range value for column 'due' at row 1")

[jochenhebbrecht@…]

How to Reproduce

While doing a POST operation on /milestone/SPRINT 01, Trac issued an internal error.

---

I was trying to define a "due date" for the milestone, but it seems impossible to store the date in the MySQL table.

Any idea's?

---

Request parameters:

{'__FORM_TOKEN': u'6530de88bc8792bfc7f89aed',
 'action': u'edit',
 'description': u'',
 'duedate': u'1/1/2011',
 'id': u'SPRINT 01',
 'name': u'SPRINT 01'}

User agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100723 Ubuntu/10.04 (lucid) Firefox/3.6.8

System Information

Trac	0.12
Genshi	0.6
mod_wsgi	3.0 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})
MySQL	server: "5.1.31-community-log", client: "5.1.33", thread-safe: 1
MySQLdb	1.2.2
Python	2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)]
setuptools	0.6c11
Subversion	1.6.6 (r40053)
jQuery	1.4.2

Enabled Plugins

littlemary	1.0
ticketimport	0.8
timingandestimationplugin	1.0.5b
tracaccountmanager	0.2.1dev-r7737
tracburndown	1.9.2
tracthemeengine	2.0.1

Python Traceback

Traceback (most recent call last):
  File "C:\Program Files\Python26\lib\site-packages\trac\web\main.py", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File "C:\Program Files\Python26\lib\site-packages\trac\web\main.py", line 235, in dispatch
    resp = chosen_handler.process_request(req)
  File "C:\Program Files\Python26\lib\site-packages\trac\ticket\roadmap.py", line 591, in process_request
    return self._do_save(req, db, milestone)
  File "C:\Program Files\Python26\lib\site-packages\trac\ticket\roadmap.py", line 673, in _do_save
    milestone.update()
  File "C:\Program Files\Python26\lib\site-packages\trac\ticket\model.py", line 1004, in update
    @self.env.with_transaction(db)
  File "C:\Program Files\Python26\lib\site-packages\trac\db\api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "C:\Program Files\Python26\lib\site-packages\trac\ticket\model.py", line 1014, in do_update
    self.description, old_name))
  File "C:\Program Files\Python26\lib\site-packages\trac\db\util.py", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "C:\Program Files\Python26\lib\site-packages\MySQLdb\cursors.py", line 166, in execute
    self.errorhandler(self, exc, value)
  File "C:\Program Files\Python26\lib\site-packages\MySQLdb\connections.py", line 35, in defaulterrorhandler
    raise errorclass, errorvalue
DataError: (1264, "Out of range value for column 'due' at row 1")

[Remy Blank]

There's something wrong with your database schema. The due row of the milestone table should be a bigint, but this doesn't seem to be the case here. Did you create the environment with 0.12, or did you upgrade from a previous release? In the latter case, did you have any issues during the upgrade? Did you customize the database schema in any way?

[anonymous]

Hmm, that column is of type "int(11)", not bigint:

mysql> describe milestone;
+-------------+---------+------+-----+---------+-------+
| Field       | Type    | Null | Key | Default | Extra |
+-------------+---------+------+-----+---------+-------+
| name        | text    | NO   | PRI | NULL    |       |
| due         | int(11) | YES  |     | NULL    |       |
| completed   | int(11) | YES  |     | NULL    |       |
| description | text    | YES  |     | NULL    |       |
| started     | int(11) | YES  |     | NULL    |       |
+-------------+---------+------+-----+---------+-------+
5 rows in set (0.05 sec)

I did a fresh install of Trac on my local machine, and due date is once again an int(11). I started from a clean 0.12 environment. I haven't upgrade from a previous version. So I didn't have issues during upgrade. And I certainly did not customize the database :-)

[Christian Boos]

Server version: 5.0.67-community-nt MySQL Community Edition (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> describe milestone;
+-------------+------------+------+-----+---------+-------+
| Field       | Type       | Null | Key | Default | Extra |
+-------------+------------+------+-----+---------+-------+
| name        | text       | NO   | PRI | NULL    |       |
| due         | bigint(20) | YES  |     | NULL    |       |
| completed   | bigint(20) | YES  |     | NULL    |       |
| description | text       | YES  |     | NULL    |       |
+-------------+------------+------+-----+---------+-------+
4 rows in set (0.39 sec)

Which version of MySQL do you have?

[Christian Boos]

Ah, and btw. you have an extra started column, so most likely you have a plugin which takes over the regular milestone table and creates or recreates it its own way…

[Remy Blank]

The version is in the description (5.1.31-community-log). I have the same table as cboos, so the plugin explanation is very likely. My guess would be the timing and estimation or the burndown plugin.

[anonymous]

Hmm, it could be, but the strange thing is: this is the table on a newly created environment. So no plugins in there? :-) … Anywayz, I'll try to change the column types. I'll let you know if it works! :-)

mysql> describe milestone;
+-------------+---------+------+-----+---------+-------+
| Field       | Type    | Null | Key | Default | Extra |
+-------------+---------+------+-----+---------+-------+
| name        | text    | NO   | PRI | NULL    |       |
| due         | int(11) | YES  |     | NULL    |       |
| completed   | int(11) | YES  |     | NULL    |       |
| description | text    | YES  |     | NULL    |       |
+-------------+---------+------+-----+---------+-------+
4 rows in set (0.00 sec)

[Remy Blank]

Yes, it's the ​ScrumBurndownPlugin that adds the started column by re-creating the whole table, unfortunately with int times instead of bigint. Actually, according to ​this page, it seems that the plugin doesn't support 0.12 yet.

So, this is a PluginIssue.

[Jochen]

I solved the problem by doing this:

ALTER TABLE `milestone` CHANGE `due` `due` BIGINT( 20 ) NULL DEFAULT NULL 

[Jochen]

rblank,

Thanks. That must have been the problem.

Jochen

[Remy Blank]

You may want to do the same operation on the completed column.