DAL reads information from app/databases.
If you delete it's contents, but do not delete tables in database, you will
get error "table already exists". You can use
migrate=False,false_migrate=True to fix this.
If you delete tables in database, but do not delete contents of
app/databases, you will get error "table does not exist". DAL thinks tables
are already there, because you kept app/databases files.
DAL is cool and easy, read the DAL section of the web2py.com/book :)
Marin
On Thu, Jan 12, 2012 at 6:03 AM, Likit <lewis_le...@hotmail.com> wrote:
> I mean, why won't web2py create the tables through its famous DAL.
>
> I have created the database directly in mysql.
>
> On Jan 11, 8:44 pm, Likit <lewis_le...@hotmail.com> wrote:
> > I guess I like SQL better than frameworks. SQL is a query language for
> > DDL and DML that is well documented and completely explicitly.
> > Frameworks are opaque and invent a new syntax subject to ambiguities
> > of parens, square braces, curly braces, dotted names, sometimes
> > tablenames being implicit, sometimes fieldnames being implicit. Why?
> >
> > So, I have repeatedly tried to make a link table like the famous dogs
> > and owners tables in the Web2py book to no avail.
> >
> > Each time there is a problem I must do the following:
> > - drop the database from mysql
> > - stop apache
> > - stop mysql
> > - delete the web2py application via the filesystem
> > - restore the web2py application via the filesystem making sure that
> > the cache and session files have been deleted
> > - restart apache
> > - restart mysql
> > - create the empty database in mysql
> > - run the web2py application
> >
> > But, web2py's DAL fails to create the tables. Because the errors
> > appear to be in the framework itself, the diagnostics are completely
> > opaque through several layers of calls. The ultimate error is that one
> > of the tables is not being created. But, that is circular--that is
> > because the DAL failed to create the table for a brand new web2py
> > application in an empty database.
> >
> > Judging from the references below it is because of a faulty
> > migration. it's not like the most trivial migrations EVER work. it
> > appears that some detritus of the previous application or tables
> > exists so that web2py attempts its failed magic by doing a migration.
> >
> > So, perhaps the real question is how does one purge every possible
> > vestige of both the tables and application so that web2py does not try
> > any of its so-called magic (which is supposed to be very unpythonic,
> > in any case).
> >
> > I've wasted nearly 60 hours on web2py and am about to stop wasting any
> > more time. There seem to be many reasons that php, jquery, and RonR
> > have dusted python for web development.
> >
> > Here is the traceback:
> >
> > TRACEBACK
> >
> > Traceback (most recent call last):
> > File "C:\web2py\gluon\restricted.py", line 204, in restricted
> > exec ccode in environment
> > File "C:/web2py/applications/pyjokes/models/db.py", line 55, in
> > <module>
> > Field('category_id', 'integer'))
> > File "C:\web2py\gluon\dal.py", line 5097, in define_table
> > polymodel=polymodel)
> > File "C:\web2py\gluon\dal.py", line 728, in create_table
> > fake_migrate=fake_migrate)
> > File "C:\web2py\gluon\dal.py", line 816, in migrate_table
> > self.execute(sub_query)
> > File "C:\web2py\gluon\dal.py", line 1359, in execute
> > return self.log_execute(*a, **b)
> > File "C:\web2py\gluon\dal.py", line 1353, in log_execute
> > ret = self.cursor.execute(*a, **b)
> > File "C:\web2py\gluon\contrib\pymysql\cursors.py", line 108, in
> > execute
> > self.errorhandler(self, exc, value)
> > File "C:\web2py\gluon\contrib\pymysql\connections.py", line 184, in
> > defaulterrorhandler
> > raise errorclass, errorvalue
> > ProgrammingError: (1146, u"Table 'jodb.joke_category' doesn't exist")
>
