sudr / dbdeploy

Automatically exported from code.google.com/p/dbdeploy
0 stars 0 forks source link

Cannot use script numbers greater than 999 #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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