What I have issues with (perhaps wrongly) is the complication in distinguishing migrate and fake_migrate. I'm not talking about where it is used (in DAL(...) or in define_tables(...)).
I think there's a logical thing in terminology that might needs to straighten up, whenever appropriate. On Apr 26, 10:55 am, Anthony <[email protected]> wrote: > 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
