On Tuesday, April 26, 2011 11:42:03 AM UTC-4, VP wrote:
>
>
>
> On Apr 25, 5:09 pm, Massimo Di Pierro <[email protected]>
> wrote:
> > this case you must run with
> >
> > DAL(....,migrate_enabled=True, fake_migrate_enabled=True)
> >
>
> Does DAL(....,migrate_enabled=False, fake_migrate_enabled=True) work
> exactly the same as DAL(....,migrate_enabled=True,
> fake_migrate_enabled=True)?
>
> I don't think I fully understand migrate and fake_migrate. That said,
> the term "fake_migrate" sounds like a hack, an afterthought. The term
> sounds as if fake_migrate exists because migrate doesn't do a good
> job.
The 'migrate' argument to DAL actually just sets the default value of
'migrate' for any call to define_table() that doesn't explicitly set the
'migrate' argument. So, for example, if you have:
db = DAL(..., migrate = True)
db.define_table('table1', ...)
db.define_table('table2', ..., migrate = False)
then migrations will be on for table1 (because there is no 'migrate'
argument in table1's define_table, 'migrate' defaults to True for table1).
However, migrations will be off for table2 because 'migrate' is explicitly
set to False in its define_table. DAL(..., fake_migrate=...) works the same
way (i.e., it merely sets the default when define_table doesn't explicitly
include a 'fake_migrate' argument). We have to keep this behavior for
backward compatibility.
The new arguments added to DAL are migrate_enabled (it defaults to True, but
if you set it to False, you can force all migrations to be turned off,
regardless of the individual define_table arguments) and fake_migrate_all
(it defaults to False, but if you set it to True, you can force fake
migration of all tables). Note, fake_migrate_all was mistakenly named
fake_migrate_enabled, but that has been fixed in trunk.
Anthony
