Voltron
You weren't absolutely specific, so just to clarify, when you say
"upload" do you mean using the web2py admin "upload application"
function?
Let's assume for the time being that the answer is "yes" both on the
initial upload and the "weeks after" scenario.
As you say, on the initial upload, no problemo.
In the "weeks after" scenario, from my testing, I would suggest that
you:
- do NOT remove the application on the BETA server
- copy the packed tar to the BETA server/applications/your_app folder
- unpack it manually: tar -xvf web2py.app.your_app.tar
- if your local and BETA database are NOT the same name/username/
password/etc then modify the BETA model (db.py?) accordingly
- that's it - use app
NOTE: as stated previously, this would not work if your database is
stored within the web2py application folder structure. Taking SQLLite
as an example, your local databases/db.db would be contained in the
packed tar and would overwrite your BETA database!
Let me know if this works for you. I agree that upgrading a version
of an application should be more transparent than this, however, I do
not know enough to suggest how this would done within web2py admin.
On Oct 26, 1:02 pm, voltron <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
