What is wrong with the second solution?
$ python web2py.py -S atest
>>> db=SQLDB(None)
>>> db['_dbname']='mysql'
>>>
db.define_table('person',SQLField('name'))._create(migrate='person.table')
Massimo
On Oct 26, 6:02 am, voltron <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
