Hi, I just filed a bug report for session.connect resulting in an internal error with PostgreSQL as DB and the parameter migrate set to False (Issue 1814 <http://code.google.com/p/web2py/issues/detail?id=1814>, about session.connect ignoring the migrate=False parameter).
To go further from the bug report, something in the code of the web2py session (gluon.globals.session) met my eye which I don't quite understand. Perhaps someone could help me with that. The current code to decide whether the table should be migrated or not is as follows: table_migrate = (masterapp == request.application) So it does a migration when the masterapp is the same as the current application. Which in my eyes is under normal circumstances everytime. Is that really needed? Or would it be better just to migrate when the application changed and the database table does not exist? It seems to me, that was at least for the first part the case in the old code (as of 2.5.1): if masterapp == request.application: table_migrate = migrate else: table_migrate = False But here, when you would possibly need a new session table (since the application changed) you won't migrate. Hmm. I don't quite understand that. So, what is exactly happening during migration? What is the meaning of migrate = True? Does the web2py stack just do a CREATE TABLE ... or does it check the schema and then decide whether to adapt the schema or leave it be? Or is there a position in between the database and the define_table where web2py checks for schema integrity? The reason why I ask this is, that I had a lot of pain transferring from SQLite to PostgreSQL, resulting in many internal errors coming from PostgreSQL complaining about already existing tables. For a running application you can just set migrate=False, which works well, but you have to care for yourself about the database scheme. The workflow for me I came up with is, that I manually create the table in the db, either in raw SQL on the database's command line or by doing it with web2py scripts, setting migrate to True. So I can let the application happily run with migrate=False. Perhaps it would be a possibility to change the behaviour of DAL considering the migrations in combination with PostgreSQL (and possibly other database engines) to prevent such errors? I can offer to do that effort since I work regularily with PostgreSQL and run in many errors of that type. That would give the same pretty behaviour as with SQLite where you can just let web2py care about the database scheme or at least prevent postgres errors on trying to newly create already existing tables. But I'm not sure this is a bug. I like to understand the reasons behind this, and whether that is an application or web2py specific issue. Regards, Lukas -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
