You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 16, 2021. It is now read-only.
Hi guys ...
me and friend just found out that there is a bug in your freemaker templates.
When you scripts that have a index number higher than 999 (ie 1000 and up) the
changelog insert will fail. This is because freemaker formats numbers when
printing them out.
So for example when i create a script
1500-my_test_script.sql
following output is produced:
INSERT INTO changelog (change_number, complete_dt, applied_by, description)
VALUES (1,500, CURRENT_TIMESTAMP, USER(), '1500-my_test_script.sql');
and this of course fails.
The solution is to change all the freemaker templates. For example
mysql_apply.ftl
needs to change to this (added a ?string.number after script.id)
INSERT INTO ${changeLogTableName} (change_number, complete_dt, applied_by,
description)
VALUES (${script.id?string.number}, CURRENT_TIMESTAMP, USER(), '${script.description}');
here is the section in the freemaker manual that describes exactly this problem
:)
http://freemarker.sourceforge.net/docs/ref_builtins_number.html
i hope you guys can fix that very quick since I already showed you how to fix
it... :)
Thanks
Chris
Original issue reported on code.google.com by imbaRox...@gmail.com on 31 Aug 2010 at 12:24
Thanks Chris,
You save my time on searching the relevant information.
I would say ${script.id?string.number} is not working in my environment as my
local is not using the 'en_US'.
Instead I've put followings in the top of every freemarker templates after the
[#ftl] tag:
[#setting number_format="0"]
Here is the reference:
http://freemarker.sourceforge.net/docs/ref_directive_setting.html#ref.setting.nu
mber_format
Original comment by onionhea...@gmail.com on 2 Dec 2010 at 7:04
This is a duplicate of issue 36, which was fixed r135.
Apologies for such a dumb error :(
I'll be looking to create a new binary release in the next few days hopefully
as this is such a critical bug.
Original comment by gtack...@googlemail.com on 23 Feb 2011 at 5:38
Original issue reported on code.google.com by
imbaRox...@gmail.com
on 31 Aug 2010 at 12:24The text was updated successfully, but these errors were encountered: