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)