[web2py] Re: Deploying DB
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.
[web2py] Re: Deploying DB
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.
[web2py] Re: Deploying DB
The duplicate .table files from what I can tell come from using different database connection strings. I haven't looked for the code but I do know if I change the database type, user name etc in the DAL() connection string parameter it appears to generate a hash code from the string and prefix that onto the table name and then .table as the extension. If you were to look in your development environment I am guessing one of the prefixes in your production set matches and if the production db connection string is different I am reasonably sure it will be using the other set of .table files. Except for SQLite I have found it only makes sense to preserve the database directory across installation instances if you use the exact same database connection string in both installations. Then I copy the database across using the database specific dump restore. If I get the tables already created error because I changed something I drop the database, clear out the databases directory, create an empty database, run the application up once to create an empty table and relations set and then load the data using the import from cvs file method. Now that I know what fake_migrate does I might try that next time by just deleting the .table files. My db is small containing configuration data for the application mostly so it isn't much of a hardship to toss these around. When the db is large it is a totally different matter that requires a lot more effort and time.
[web2py] Re: Deploying DB
Thank you for your reply, On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com wrote: On a new database you should run at least once with migrate=True and then you can set migrate=False and it should work. I did it, and didn't work. If you are getting the errors below I assume you have migrate=True and missing database/*.table files. You must have deleted them. Nope, it's error just happens when I change from SQLite to Postgre, using SQlite all works fine, then I change to Postgre it works without issue while migrate = True, if I switch it to False Application complaint with described error. In this case you must run with DAL(,migrate_enabled=True, fake_migrate_enabled=True) and it will rebuild the missing .table files. Mind the process is not guaranteed to recover the missing files. I don't care to recover any data, I just want that it work without issue. On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote: Sorry again, The error is: ProgrammingError: relation auth_user already exists Oscar. On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote: BTW I tried with migration set to False locally with SqLite and it worked without issues. Oscar. On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote: Hi there, I'm triying to deploy a W2P project based on Wiki_Plugin. I just installed the plugin, I did some tests using sqlite, then I wanted to deploy the code over my server based on PostgreSQL, I did the same and it worked with migrations set to True, but wiki plugins has a comment where I must set to False the migration in a production environment, I did set it but the application fails. The error is related with auth_user table already exists, so If migrations are turned off, is the default behaviour of w2p consider all tables as these already exists? How I can fix this? Regards, Oscar. Regards, Oscar.
[web2py] Re: Deploying DB
Than the safe way is:
1) delete database
2) recreate database (empty, no tables)
3 use
DAL('mysql://...') # the default with no arguments like
migrate_enabled=True, fake_migrate_enabled=True
On Apr 26, 1:03 am, Oscar oscar.m...@gmail.com wrote:
Thank you for your reply,
On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
On a new database you should run at least once with migrate=True and
then you can set migrate=False and it should work.
I did it, and didn't work.
If you are getting the errors below I assume you have migrate=True and
missing database/*.table files. You must have deleted them.
Nope, it's error just happens when I change from SQLite to Postgre,
using SQlite all works fine, then I change to Postgre it works without
issue while migrate = True, if I switch it to False Application
complaint with described error.
In this case you must run with
DAL(,migrate_enabled=True, fake_migrate_enabled=True)
and it will rebuild the missing .table files.
Mind the process is not guaranteed to recover the missing files.
I don't care to recover any data, I just want that it work without
issue.
On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote:
Sorry again,
The error is: ProgrammingError: relation auth_user already exists
Oscar.
On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote:
BTW I tried with migration set to False locally with SqLite and it
worked without issues.
Oscar.
On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote:
Hi there,
I'm triying to deploy a W2P project based on Wiki_Plugin. I just
installed the plugin, I did some tests using sqlite, then I wanted to
deploy the code over my server based on PostgreSQL, I did the same and
it worked with migrations set to True, but wiki plugins has a comment
where I must set to False the migration in a production environment, I
did set it but the application fails. The error is related with
auth_user table already exists, so If migrations are turned off, is
the default behaviour of w2p consider all tables as these already
exists?
How I can fix this?
Regards,
Oscar.
Regards,
Oscar.
Re: [web2py] Re: Deploying DB
And how do I update the structure of the database in production? I can not
delete it andcreate again.
_
*Gilson Filho*
*Web Developer
http://gilsondev.com*
2011/4/26 Massimo Di Pierro massimo.dipie...@gmail.com
Than the safe way is:
1) delete database
2) recreate database (empty, no tables)
3 use
DAL('mysql://...') # the default with no arguments like
migrate_enabled=True, fake_migrate_enabled=True
On Apr 26, 1:03 am, Oscar oscar.m...@gmail.com wrote:
Thank you for your reply,
On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
On a new database you should run at least once with migrate=True and
then you can set migrate=False and it should work.
I did it, and didn't work.
If you are getting the errors below I assume you have migrate=True and
missing database/*.table files. You must have deleted them.
Nope, it's error just happens when I change from SQLite to Postgre,
using SQlite all works fine, then I change to Postgre it works without
issue while migrate = True, if I switch it to False Application
complaint with described error.
In this case you must run with
DAL(,migrate_enabled=True, fake_migrate_enabled=True)
and it will rebuild the missing .table files.
Mind the process is not guaranteed to recover the missing files.
I don't care to recover any data, I just want that it work without
issue.
On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote:
Sorry again,
The error is: ProgrammingError: relation auth_user already exists
Oscar.
On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote:
BTW I tried with migration set to False locally with SqLite and it
worked without issues.
Oscar.
On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote:
Hi there,
I'm triying to deploy a W2P project based on Wiki_Plugin. I just
installed the plugin, I did some tests using sqlite, then I
wanted to
deploy the code over my server based on PostgreSQL, I did the
same and
it worked with migrations set to True, but wiki plugins has a
comment
where I must set to False the migration in a production
environment, I
did set it but the application fails. The error is related with
auth_user table already exists, so If migrations are turned off,
is
the default behaviour of w2p consider all tables as these already
exists?
How I can fix this?
Regards,
Oscar.
Regards,
Oscar.
[web2py] Re: Deploying DB
It applies for Postgre too?
Oscar.
On 26 abr, 08:23, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
Than the safe way is:
1) delete database
2) recreate database (empty, no tables)
3 use
DAL('mysql://...') # the default with no arguments like
migrate_enabled=True, fake_migrate_enabled=True
On Apr 26, 1:03 am, Oscar oscar.m...@gmail.com wrote:
Thank you for your reply,
On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
On a new database you should run at least once with migrate=True and
then you can set migrate=False and it should work.
I did it, and didn't work.
If you are getting the errors below I assume you have migrate=True and
missing database/*.table files. You must have deleted them.
Nope, it's error just happens when I change from SQLite to Postgre,
using SQlite all works fine, then I change to Postgre it works without
issue while migrate = True, if I switch it to False Application
complaint with described error.
In this case you must run with
DAL(,migrate_enabled=True, fake_migrate_enabled=True)
and it will rebuild the missing .table files.
Mind the process is not guaranteed to recover the missing files.
I don't care to recover any data, I just want that it work without
issue.
On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote:
Sorry again,
The error is: ProgrammingError: relation auth_user already exists
Oscar.
On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote:
BTW I tried with migration set to False locally with SqLite and it
worked without issues.
Oscar.
On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote:
Hi there,
I'm triying to deploy a W2P project based on Wiki_Plugin. I just
installed the plugin, I did some tests using sqlite, then I wanted
to
deploy the code over my server based on PostgreSQL, I did the same
and
it worked with migrations set to True, but wiki plugins has a
comment
where I must set to False the migration in a production
environment, I
did set it but the application fails. The error is related with
auth_user table already exists, so If migrations are turned off, is
the default behaviour of w2p consider all tables as these already
exists?
How I can fix this?
Regards,
Oscar.
Regards,
Oscar.
[web2py] Re: Deploying DB
So,
If I don't use any argument at all, does Web2py set true as default?
Oscar.
On 26 abr, 08:23, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
Than the safe way is:
1) delete database
2) recreate database (empty, no tables)
3 use
DAL('mysql://...') # the default with no arguments like
migrate_enabled=True, fake_migrate_enabled=True
On Apr 26, 1:03 am, Oscar oscar.m...@gmail.com wrote:
Thank you for your reply,
On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
On a new database you should run at least once with migrate=True and
then you can set migrate=False and it should work.
I did it, and didn't work.
If you are getting the errors below I assume you have migrate=True and
missing database/*.table files. You must have deleted them.
Nope, it's error just happens when I change from SQLite to Postgre,
using SQlite all works fine, then I change to Postgre it works without
issue while migrate = True, if I switch it to False Application
complaint with described error.
In this case you must run with
DAL(,migrate_enabled=True, fake_migrate_enabled=True)
and it will rebuild the missing .table files.
Mind the process is not guaranteed to recover the missing files.
I don't care to recover any data, I just want that it work without
issue.
On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote:
Sorry again,
The error is: ProgrammingError: relation auth_user already exists
Oscar.
On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote:
BTW I tried with migration set to False locally with SqLite and it
worked without issues.
Oscar.
On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote:
Hi there,
I'm triying to deploy a W2P project based on Wiki_Plugin. I just
installed the plugin, I did some tests using sqlite, then I wanted
to
deploy the code over my server based on PostgreSQL, I did the same
and
it worked with migrations set to True, but wiki plugins has a
comment
where I must set to False the migration in a production
environment, I
did set it but the application fails. The error is related with
auth_user table already exists, so If migrations are turned off, is
the default behaviour of w2p consider all tables as these already
exists?
How I can fix this?
Regards,
Oscar.
Regards,
Oscar.
[web2py] Re: Deploying DB
On Apr 25, 5:09 pm, Massimo Di Pierro massimo.dipie...@gmail.com 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. Another thing is with 2 Boolean variables (migrate and fake_migrate), there are 4 possibilities, but it seems that 2 of those possibilities work exactly the same. If this understanding is true, can we simplify the situation and reduce 2 variables to 1. Say, call it migrate, which has only 3 possibilities: (a) off - no migration, assuming models and pickled files are consistent. (b) on - migration, will attempt to insert/delete fields,tables to make picked files consistent with models. (c) forced - will force pickle files to be consistent with models, no matter what. This is equivalent to fake_migrate=True.
[web2py] Re: Deploying DB
On Tuesday, April 26, 2011 11:42:03 AM UTC-4, VP wrote:
On Apr 25, 5:09 pm, Massimo Di Pierro massimo@gmail.com
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
[web2py] Re: Deploying DB
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 abasta...@gmail.com wrote:
On Tuesday, April 26, 2011 11:42:03 AM UTC-4, VP wrote:
On Apr 25, 5:09 pm, Massimo Di Pierro massimo@gmail.com
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
[web2py] Re: Deploying DB
I tried to use migrate_enabled but i having returned the following
error:
p4089
sS'key'
p4090
S'migrate_enabled'
p4091
sssS'traceback'
p4092
S'Traceback (most recent call last):\n File /home/dotcloud/current/
gluon/restricted.py, line 181, in restricted\nexec ccode in
environment\n File /home/dotcloud/1303836474.97/applications/wiki/
models/plugin_wiki.py, line 63, in module\nformat = \'%(slug)s
\', migrate_enabled=plugin_wiki_migrate)\n File /home/dotcloud/
current/gluon/dal.py, line 3992, in define_table\nraise
SyntaxError, \'invalid table %s attribute: %s\' % (tablename, key)
\nSyntaxError: invalid table plugin_wiki_page attribute:
migrate_enabled\n'
p4093
Oscar.
On 26 abr, 08:23, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
Than the safe way is:
1) delete database
2) recreate database (empty, no tables)
3 use
DAL('mysql://...') # the default with no arguments like
migrate_enabled=True, fake_migrate_enabled=True
On Apr 26, 1:03 am, Oscar oscar.m...@gmail.com wrote:
Thank you for your reply,
On 25 abr, 18:09, Massimo Di Pierro massimo.dipie...@gmail.com
wrote:
On a new database you should run at least once with migrate=True and
then you can set migrate=False and it should work.
I did it, and didn't work.
If you are getting the errors below I assume you have migrate=True and
missing database/*.table files. You must have deleted them.
Nope, it's error just happens when I change from SQLite to Postgre,
using SQlite all works fine, then I change to Postgre it works without
issue while migrate = True, if I switch it to False Application
complaint with described error.
In this case you must run with
DAL(,migrate_enabled=True, fake_migrate_enabled=True)
and it will rebuild the missing .table files.
Mind the process is not guaranteed to recover the missing files.
I don't care to recover any data, I just want that it work without
issue.
On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote:
Sorry again,
The error is: ProgrammingError: relation auth_user already exists
Oscar.
On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote:
BTW I tried with migration set to False locally with SqLite and it
worked without issues.
Oscar.
On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote:
Hi there,
I'm triying to deploy a W2P project based on Wiki_Plugin. I just
installed the plugin, I did some tests using sqlite, then I wanted
to
deploy the code over my server based on PostgreSQL, I did the same
and
it worked with migrations set to True, but wiki plugins has a
comment
where I must set to False the migration in a production
environment, I
did set it but the application fails. The error is related with
auth_user table already exists, so If migrations are turned off, is
the default behaviour of w2p consider all tables as these already
exists?
How I can fix this?
Regards,
Oscar.
Regards,
Oscar.
[web2py] Re: Deploying DB
On Tuesday, April 26, 2011 12:44:26 PM UTC-4, VP wrote: 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. I suppose you could call it something like rebuild_metadata, but we'd still need to keep fake_migrate for backward compatibility.
[web2py] Re: Deploying DB
A new name might not be a bad idea both because fake_migrate isn't that clear and it does sound hacky. I've just rolled my database into production and have been struggling with migrations so any extra clarity would really help. It seems to me that something like rebuild metadata should be triggerable from admin? Is there a discussion anywhere on how to use the various settings and database log files to administer a production DB? For example, my sql.log file is a few thousand lines long now, mostly with duplicate failed migrations. And I have duplicate .table files now which Im not sure what to do with. And what migrations to avoid and how to do them if you have to?
[web2py] Re: Deploying DB
BTW I tried with migration set to False locally with SqLite and it worked without issues. Oscar. On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote: Hi there, I'm triying to deploy a W2P project based on Wiki_Plugin. I just installed the plugin, I did some tests using sqlite, then I wanted to deploy the code over my server based on PostgreSQL, I did the same and it worked with migrations set to True, but wiki plugins has a comment where I must set to False the migration in a production environment, I did set it but the application fails. The error is related with auth_user table already exists, so If migrations are turned off, is the default behaviour of w2p consider all tables as these already exists? How I can fix this? Regards, Oscar.
[web2py] Re: Deploying DB
Sorry again, The error is: ProgrammingError: relation auth_user already exists Oscar. On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote: BTW I tried with migration set to False locally with SqLite and it worked without issues. Oscar. On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote: Hi there, I'm triying to deploy a W2P project based on Wiki_Plugin. I just installed the plugin, I did some tests using sqlite, then I wanted to deploy the code over my server based on PostgreSQL, I did the same and it worked with migrations set to True, but wiki plugins has a comment where I must set to False the migration in a production environment, I did set it but the application fails. The error is related with auth_user table already exists, so If migrations are turned off, is the default behaviour of w2p consider all tables as these already exists? How I can fix this? Regards, Oscar.
[web2py] Re: Deploying DB
On a new database you should run at least once with migrate=True and then you can set migrate=False and it should work. If you are getting the errors below I assume you have migrate=True and missing database/*.table files. You must have deleted them. In this case you must run with DAL(,migrate_enabled=True, fake_migrate_enabled=True) and it will rebuild the missing .table files. Mind the process is not guaranteed to recover the missing files. On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote: Sorry again, The error is: ProgrammingError: relation auth_user already exists Oscar. On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote: BTW I tried with migration set to False locally with SqLite and it worked without issues. Oscar. On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote: Hi there, I'm triying to deploy a W2P project based on Wiki_Plugin. I just installed the plugin, I did some tests using sqlite, then I wanted to deploy the code over my server based on PostgreSQL, I did the same and it worked with migrations set to True, but wiki plugins has a comment where I must set to False the migration in a production environment, I did set it but the application fails. The error is related with auth_user table already exists, so If migrations are turned off, is the default behaviour of w2p consider all tables as these already exists? How I can fix this? Regards, Oscar.
[web2py] Re: Deploying DB
Hi Massimo, I have seen migrate=T/F, but not migrate_enabled=T/F Is this new, or something PostgreSQL specific? Thanks, Mart :) On Apr 25, 6:09 pm, Massimo Di Pierro massimo.dipie...@gmail.com wrote: On a new database you should run at least once with migrate=True and then you can set migrate=False and it should work. If you are getting the errors below I assume you have migrate=True and missing database/*.table files. You must have deleted them. In this case you must run with DAL(,migrate_enabled=True, fake_migrate_enabled=True) and it will rebuild the missing .table files. Mind the process is not guaranteed to recover the missing files. On Apr 25, 3:39 pm, Oscar oscar.m...@gmail.com wrote: Sorry again, The error is: ProgrammingError: relation auth_user already exists Oscar. On 25 abr, 16:34, Oscar oscar.m...@gmail.com wrote: BTW I tried with migration set to False locally with SqLite and it worked without issues. Oscar. On 25 abr, 16:32, Oscar oscar.m...@gmail.com wrote: Hi there, I'm triying to deploy a W2P project based on Wiki_Plugin. I just installed the plugin, I did some tests using sqlite, then I wanted to deploy the code over my server based on PostgreSQL, I did the same and it worked with migrations set to True, but wiki plugins has a comment where I must set to False the migration in a production environment, I did set it but the application fails. The error is related with auth_user table already exists, so If migrations are turned off, is the default behaviour of w2p consider all tables as these already exists? How I can fix this? Regards, Oscar.
[web2py] Re: Deploying DB
New in 1.95.1 as of today: https://groups.google.com/d/topic/web2py/oer8IeJ6dc8/discussion
[web2py] Re: Deploying DB
On Monday, April 25, 2011 8:02:48 PM UTC-4, mart wrote: Hi Massimo, I have seen migrate=T/F, but not migrate_enabled=T/F If you specify DAL(..., migrate_enabled=False), it will turn off all migrations, regardless of how the 'migrate' argument is set in individual tables -- so it's a quick way to completely disable all migrations. There's also a new argument to DAL called fake_migrate_all (which defaults to False). If you specify DAL(..., fake_migrate_all=True), it will force a fake_migrate of all tables, regardless of how the 'fake_migrate' argument is set in individual tables -- so, it's a quick way to fake_migrate all tables to fix broken migrations ( http://web2py.com/book/default/chapter/06#Fixing-Broken-Migrations). Note, I think in 1.95.1, this new argument was actually named fake_migrate_enabled, but it has been changed to fake_migrate_all in trunk to better reflect what it actually does. Anthony
[web2py] Re: Deploying DB
nice! I searched the book, but couldn't find a reference to 'migrate_enabled'. Thanks for the info, will come in handy! :) On Apr 25, 8:20 pm, Anthony abasta...@gmail.com wrote: On Monday, April 25, 2011 8:02:48 PM UTC-4, mart wrote: Hi Massimo, I have seen migrate=T/F, but not migrate_enabled=T/F If you specify DAL(..., migrate_enabled=False), it will turn off all migrations, regardless of how the 'migrate' argument is set in individual tables -- so it's a quick way to completely disable all migrations. There's also a new argument to DAL called fake_migrate_all (which defaults to False). If you specify DAL(..., fake_migrate_all=True), it will force a fake_migrate of all tables, regardless of how the 'fake_migrate' argument is set in individual tables -- so, it's a quick way to fake_migrate all tables to fix broken migrations (http://web2py.com/book/default/chapter/06#Fixing-Broken-Migrations). Note, I think in 1.95.1, this new argument was actually named fake_migrate_enabled, but it has been changed to fake_migrate_all in trunk to better reflect what it actually does. Anthony
