Closed GoogleCodeExporter closed 8 years ago
I have set the CommandTimeout to 90 seconds instead of the default of 30
seconds.
This should cover most cases of large migrations.
resolved in r113
Original comment by dko...@gmail.com
on 6 Aug 2008 at 1:06
Perhaps this could be addressed like so:
[Migration(42, Timeout = 600)]
public class MigrationThatMightTake10Minutes : Migration
{
...
}
10 minutes for a migration!!! I've got one - it iterates over a cursor which
corrects bad data in a very large table. After correcting the data, it applies
a new
stricter constraint so that the data can't be damaged again.
Original comment by rawdatad...@gmail.com
on 23 Dec 2008 at 9:56
I am still having the issue, 90s is still not suffisant in some scenarios (some
of them include big SQL Scripts which can take a while to complete)...
Original comment by homebo...@gmail.com
on 10 Jul 2010 at 12:38
having the same issue. Have to create an index on the large table..
Original comment by demchenk...@gmail.com
on 14 Dec 2010 at 12:31
had the same issue (creating index on a very large table), looked around the
source and decided to do this work-around (i know its a bit ugly but it does
what it should):
public static class MigrationsExtender
{
public static int ExecuteNonQuery(this ITransformationProvider itp, string sql, int timeout)
{
itp.Logger.Trace(sql);
itp.Logger.ApplyingDBChange(sql);
IDbCommand ic = itp.GetCommand();
ic.CommandText = sql;
ic.CommandTimeout = timeout;
try { return ic.ExecuteNonQuery(); }
catch (Exception up)
{
itp.Logger.Warn(up.Message);
throw up;
}
}
}
Original comment by abeldedo...@gmail.com
on 20 May 2011 at 10:32
Original issue reported on code.google.com by
jaspervo...@gmail.com
on 30 Jul 2008 at 1:21