As arguments to DAL, 'migrate' and 'migrate_enabled' do not do the same
thing (the former sets the default for all define_table calls that lack an
explicit 'migrate' argument, and the latter simply enables or disables all
migrations), but they both default to True, so explicitly setting them as
you have below should not make a difference.
'fake_migrate' (like 'migrate') simply sets the default for define_table
calls that lack an explicit 'fake_migrate' argument, and 'fake_migrate_all'
is supposed to force fake migration of all tables, regardless of any
explicit 'fake_migrate' arguments set in individual define_table calls. If
you don't have any 'fake_migrate' arguments set in any of your define_table
calls, I would expect that setting DAL(..., fake_migrate=True) and DAL(...,
fake_migrate_all=True) would have the same effect (though for different
reasons). The fact that they don't seems to indicate a problem.
Anthony
On Friday, April 29, 2011 3:37:24 PM UTC-4, pbreit wrote:
> If I do not have any migrate/fake_migrate parameters in any of my
> define_tables, do migrate/migrate_enabled and fake_migrate/fake_migrate_all
> work the same?
>
> I don't seem to be getting the same behavior. For example:
>
> db = DAL('sqlite://storage.sqlite', migrate_enabled=True,
> fake_migrate_all=True)
> db.define_table('table1',Field('field1'))
>
> vs
>
> db = DAL('sqlite://storage.sqlite', migrate=True, fake_migrate=True)
> db.define_table('table1',Field('field1'))
>
> When I delete sql.log and the .table files (is this safe?), #1 recreates
> them all while #2 throws an error: "OperationalError: table auth_group
> already exists"
>
> I have a custom auth_user table, if that matters.
>
>
