Dumper, mySQL adapter and TIMESTAMP ... something strange?

Hi,

As explained by MiKael N. in the following post
(Problem with db_schema_import and MySQL timestamp! - Rails - Ruby-Forum) it seems that there’s a
problem with the way the mySQL adapter treats the TIMESTAMP column.

Actually, when an SQL schema with for example:

created_on TIMESTAMP

is dumped into ruby schema, it will lead to:

t.column “created_on”, :timestamp, :limit => 14

but if we try to re-import this schema in the database, the following
SQL schema is generated:

created_on DATETIME(14)

If I understand correctly the mySQL user’s guide, this seems to be an
invalid syntax: only DATETIME should be allowed.

Although I understand that there have been some problems with the way
TIMESTAMP acts between various version of mySQL, and that this leads to
using DATETIME instead of TIMESTAMP, I can’t understand why we’re
generating some invalid mySQL command here.

Looking at the mysql_adapter, it seems that the native database type
:datetime, is defined as:

:datetime => { :name => “datetime” },

and that the dumper choose whether it should add the :limit bit, based
on:

tbl.print “, :limit => #{column.limit.inspect}” if column.limit
!=@types[column.type][:limit]

Wouldn’t it make sense here to add something like the possibility to
have ‘no limit’:

tbl.print “, :limit => …” unless (@types[column.type][:limit] ==
:none) or (column.limit == @types[column.type][:limit])

and to define the :datetime type as:

:datetime => { :name => “datetime”, :limit => :none },

Once again I’m not a mySQL pro, but I think it makes sense… however
I’ve no idea of the impact on the other adapters… to my (semi-open)
eyes they seems reduce, but …

Best Regards,

Frederick R. aka Sleeper – [email protected]

Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plaugher)