I am not sure what you mean by "in a way that it survives framework
updates".

The only problems I can see would arise if:
- You delete databases/*.table but the database is still there
(updates do not cause this). Bad luck. One should not delete files, or
at least make a backup.
- Your databases/*.table are still there but you change name or login/
password for the actual database. This is not a problem. You only need
to rename the old *.table files. By default the file names are md5
hashes of the dburi string.

Notice that you can do

auth.define_table(migrate=False)

On May 5, 7:07 am, Hans <johann.scheibelho...@easytouch-edv.com>
wrote:
> Massimo,
>
> 'T2 is dead and not longer supported' is definitely a killer
> argument :-/
> If I'm not mistaken then the same problem exist with the auth_ tables.
>
> How should the db.define_table
> ('something',....,migrate='something.table') workaround be applied to
> auth_ tables in a way that it survives framework updates?
>
> Hans
>
> On May 4, 4:54 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > T2 is dead. I will be no longer be supported. In fact much of the T2
> > functionality is in gluon.tools
> > T3 will survive but will be rebuilt on top of tools and events
>
> > Massimo
>
> > On May 4, 9:39 am, Hans <johann.scheibelho...@easytouch-edv.com>
> > wrote:
>
> > > how to apply this for T2 tables like t2_person?
> > > would this workaround survive version updates of T2?
>
> > > hans
>
> > > On May 4, 4:23 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > This is complex. Currently the way to avoid the problem is to name
> > > > the .table files via
>
> > > > db.define_table('something',....,migrate='something.table')
>
> > > > using "IF EXISTS" would only solve this problem to create others.
>
> > > > Massimo
>
> > > > On May 4, 7:02 am, Hans <johann.scheibelho...@easytouch-edv.com>
> > > > wrote:
>
> > > > > I'm having a similar problem. Last time I solved it by deleting the
> > > > > database and setting it up new. With more data it gets a pain. I read
> > > > > about setting 'migrate=False' to avoid the issue. I could use that for
> > > > > 'own' tables, but I get the same error for tables created by the T2
> > > > > plugin.
> > > > > Like TheDude also I have changed the user/pass for MySQL connection.
> > > > > Maybe Web2Py thinks it needs to create the tables new after user/pass
> > > > > change?
>
> > > > > Traceback (most recent call last):
> > > > >   File "/usr/lib/web2py/gluon/restricted.py", line 98, in restricted
> > > > >     exec ccode in environment
> > > > >   File "/usr/lib/web2py/applications/ips/models/db.py", line 19, in
> > > > > <module>
> > > > >     t2=T2(request,response,session,cache,T,db)
> > > > >   File "/usr/lib/web2py/applications/plugin_t2/modules/t2.py", line
> > > > > 98, in __init__
> > > > >     self._create_tables()
> > > > >   File "/usr/lib/web2py/applications/plugin_t2/modules/t2.py", line
> > > > > 341, in _create_tables
> > > > >     t=db.define_table('t2_person',T2.base_table(db,'t2_person'))
> > > > >   File "/usr/lib/web2py/gluon/sql.py", line 938, in define_table
> > > > >     raise e
> > > > > OperationalError: (1050, "Table 't2_person' already exists")
>
> > > > > On May 4, 7:10 am, TheDude <officed...@gmail.com> wrote:
>
> > > > > > Massimo, I know that we've talked about this in the past, but here 
> > > > > > we
> > > > > > go again...
>
> > > > > > I'm using the latest web2py, in my applications, I would define 
> > > > > > tables
> > > > > > as usual only to get an SQL error saying the table exists. I tried
> > > > > > clearing out my "databases" folder, and the only way to clear out
> > > > > > would be to delete the database entirely (which is something that I
> > > > > > *should not* have to do). According to web2py docs, the DAL handles
> > > > > > this type of crap perfectly and just fine. As it should, leave the
> > > > > > migration/DAL issues to DAL and not to the user. This is what turned
> > > > > > my head towards web2py over Django.
>
> > > > > > Is CREATE TABLE `tablename` IF NOT EXISTS SQL ANSI? Either way, the
> > > > > > MySQL handler should perform this rather than just create table 
> > > > > > under
> > > > > > the next patch. It would solve *a lot* of hassle. The problem 
> > > > > > occurred
> > > > > > AFTER I changed my user/pass combo for the MySQL connection string.
> > > > > > Could this cause any problems?
>
> > > > > > Someone else had this problem unresolved a long time 
> > > > > > ago...http://groups.google.com/group/web2py/browse_thread/thread/94a7107c68...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to 
web2py+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to