Hi Niphlod,
Thanks for the quick reply.
On 21/02/13 13:18, Niphlod wrote:
I'll explain the normal behaviour, don't know if it applies to google
cloud sql.
I think its behaviour is that of MySQL.
web2py receives a request. that request execute models. in models you
have the db definition.
Understood.
If migrations are turned on (migrate=True), web2py compares the current
define_table statements with the .table files stored inside the
/databases/ folder. If a difference is found, it triggers migrations
(column add, drop, etc). If not, it continues.
Got it - so it's not looking at the db (which it assumes matches the
.table files), just comparing the .table files to the definitions in db.py.
When fake_migrate is turned on(fake_migrate=True), web2py just replaces
all the .table files inside the databases/ folder to match the
define_table statements.
Ahah - I think I see where I misunderstood.
So, if "fake_migrate" brings the .table files into sync with the
definitions, regardless of the state of the db, what I need to do to get
back in step is to make the definitions match the /actual/ state of the
db, or /vice versa/, so that all three elements are in sync?
If so, that's nice and simple!
If migrations are turned off (migrate=False), web2py uses the
define_table statements to build the environment, without checking the
.table files.
Understood.
All of this happens for all tables in one request only. If lazy_tables
is turned on instead, migrations occur when the table is accessed inside
your code.
Did I cleared the doubts ?
I think so - if I have it right above!
:-)
--
Regards,
PhilK
e: [email protected] - m: 07775 796 747
'work as if you lived in the early days of a better nation'
- alasdair gray
--
---
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.
