Hi Billf
Thanks for taking time on this. The first upload of the appliance was
done by uploading a packed(tarred) application from my loacl
workstation to the BETA server, the beta server is the checked by the
project managers and QA. When they gave the go ahead, the site was
uploaded to its LIVE location. So the packed appliance on BETA ==
packed appliance on my local computer.
Weeks after, the project manger wants a feature, this would need
changes and modifications to the model, Web2py does the ALTER to the
tables on my local machine everything is fine so I pack the appliance,
remove the existing on the BETA server( same name identical appliance)
and upload it, it is tested, green light all go. The thing is, I
cannot afford the downtime to delete the appliance on the LIVE server
and upload the modified appliance from the BETA or my local machine.
I just wonder why the same appliance cant modify and alter its tables
as smoothly as on my local machine without deleting or workaround
measures. I have to resort to doing risky live alterations on the LIVE
appliances database to make sure everything goes well.
If one can independently force a re-creation of the table files based
on a modified model, this headache would be gone, so web2opy can make
ALTER actions on a live database too as the ones on the local and BETA
(identical) applaices that passed tests
was this clear?
On 26 Okt., 13:24, billf <[EMAIL PROTECTED]> wrote:
> Voltron
>
> I apologise but I am a bit confused by your last reply. So going back
> to basics a bit, in your original post you said:
>
> "I made changes to the local version of the site on my workstation and
> uploaded to my
> "BETA" server."
>
> How exactly did you do the upload? For example:
> Did you use "pack all" on your workstation, tar the application
> manually or something else?
> On the BETA server did you use "upload application", untar a tarball
> manually or something else?
> Did you uninstall the application on the BETA server before you
> performed "upload application"?
>
> Also, where does PostgreSQL store its database files? For example,
> SQLLite stores the data file in the databases folder and it is
> included in the pack tar. MySQL stores the files elsewhere and so the
> data files are not in pack tar.
>
> On Oct 26, 11:17 am, mdipierro <[EMAIL PROTECTED]> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
