Thanks Bill and Massimo for your tests and suggestions. From what has
been posted:
Problem:
Updating and altering the database of a remote(live) appliance and its
tables form an identical local appliance
Solutions:
1. Upload and rename the local copy, delete the remote appliance,
rename the uploaded copy to the real appliance
This is a drastic solution because of the downtime
2. Recreate the database locally with a different name, copy
the .table files, make the remote appliance migrate point to them
and drop the original databse
This wont help, The database is live and has data in it already
3. Copy the altered model from the local appliance and overwrite the
model on the remote(live) appliance, delete the existing table files,
force the creation of new .table files by creating tables connected to
a None database
This seems like the same problem would occur, by chance, when a user
requests something from the database and the .table files are missing,
tickets from the appliance, my boss jumps on me
.
What speaks against having 2 switches like I proposed? It seems that I
was misunderstood. I still think that the migrate switch is ambiguous
and should on take a only Boolean value, True or False, and a
separate variable should trigger or force the creation of new .table
files when the model has been modified/changed/ altered.
Could someone explain why the changes made to a model in a local
appliance alter tables without problems and an just uploading the
model file to a identical remote appliance does not guarantee a
successful migration?
I am sorry, but I am still confused
Thanks
On 26 Okt., 10:52, mdipierro <[EMAIL PROTECTED]> wrote:
> Hi Voltron,
>
> > Would it not be better to have a varibare that notifies web2py to
> > generate the databse files or not and a separate one that toggles
> > migration?
>
> Let's consider the 4 cases Create/Migrate=TT, TF, FT, FF:
>
> TT: corresponds to migrate=True or migrate='filename'
>
> FF: corresponds to migrate=False
>
> TF: corresponds to migrate=True when you define the tables then change
> it to migrate=False
>
> FT: this is problematic. If web2py does not create the tables, it has
> no knowledge of the table structure. SQL does not define syntax to
> query the database for its table structure. I am told this can be done
> with reflections but I have not yet seen an example. Anyway there is a
> way around, which is the one Bill suggests:
>
> 1) recreate the database (a) with a different name (b)
> 2) copy the .table files created by (b) under other name and make (a)
> migrate point to them
> 3) drop (b).
>
> There is also another way around. Lets's say you have a pre-existing
> table called person with a string field name in the database. You need
> to create the .table file for it. You you can do it from the web2py
> shell:
>
> $ python web2py.py -S atest
> >>> db=SQLDB(None)
> >>> db['_dbname']='mysql'
> >>>
> db.define_table('person',SQLField('name'))._create(migrate='person.table')
>
> The first line make a connector connected to nothing, the second line
> makes it pretend it is a mysql database (of 'postgresql' or 'oracle',
> etc.), the third line defines the table and forces the creation of the
> migration file (which would not otherwise be created for a None
> database).
>
> Hope this helps.
>
> Massimo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
