That error only gets called for two reasons.
1. The table has already been defined.
2. The tablename starts with a _
Your entire application is getting restarted yes/no? The DAL object gets
instantiated with *every* request in web2py, it only stays in memory during
the life of the request, not the life of the application.
Try updated the version of sql.py, looks like your running an older version,
wouldn't hurt.
--
Thadeus
On Wed, Oct 20, 2010 at 11:11 AM, Bruno Rocha <rochacbr...@gmail.com> wrote:
> look:
>
> "connect.py"
> >>> from gluon.sql import *
> >>> db = DAL('sqlite://timeclock1.db')
> >>> Track =
> db.define_table('track',Field('regnumber','integer'),Field('action','integer'),Field('timestamp','datetime'),migrate='track.table')
>
> "Form_workflow.py"
> >>> Track.insert(regnumber=123,action=2,timestamp='2010-10-19')
> 1
> >>> Track.insert(regnumber=124,action=2,timestamp='2010-10-19')
> 2
> >>> db.commit
>
> Until here, its ok.
>
> But now I am wanting to change the model, and including Field('department')
>
> "connect.py"
> >>> Track =
> db.define_table('track',Field('regnumber','integer'),Field('action','integer'),Field('timestamp','datetime'),
> *Field('department')*,migrate='track.table')
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/bin/DAL/gluon/sql.py", line 1346, in define_table
> raise SyntaxError, 'invalid table name: %s' % tablename
> SyntaxError: invalid table name: track
> >>>
>
> 2010/10/20 Thadeus Burgess <thade...@thadeusb.com>
>
>> In my experience the dal.py does not work stand alone, however sql.py
>> does.
>>
>>
>> Table migrations have always worked for me when using standalone.
>>
>> --
>> Thadeus
>>
>>
>>
>>
>>
>> On Wed, Oct 20, 2010 at 9:58 AM, Bruno Rocha <rochacbr...@gmail.com>wrote:
>>
>>> did you specified both migrate and fake_migrate ?
>>>
>>> 2010/10/20 mart <msenecal...@gmail.com>
>>>
>>> forgot to mention something a well...
>>>>
>>>> I think the issue I had was related to yours with the migration,
>>>> because creating a table, without specifying migrate= produces the
>>>> following exception while defining a table. That migration data as
>>>> well as the parameters I passed in both get validated by
>>>> t._create(migrate=migrate, fake_migrate=fake_migrate). This is why I
>>>> think migrating or creating tables with no migration... both are
>>>> subject to the same rules, risking the same exceptions.
>>>>
>>>>
>>>> db.define_table(tableName,
>>>> SQLField('blueModuleStr'),
>>>> SQLField('blueModuleObj','blob'),
>>>> SQLField('blueModuleImports'))
>>>>
>>>>
>>>> objMakeDB.instModule(folder)
>>>> File "/Users/mart/Documents/Aptana Studio Workspace/blueLite/src/
>>>> blueLite/pyModules/createModuleTable.py", line 34, in instModule
>>>>
>>>> SQLField('blueModuleImports'))
>>>> File "/Users/mart/Documents/Aptana Studio Workspace/blueLite/src/
>>>> blueLite/pyUtils/gluon/dal.py", line 1399, in define_table
>>>>
>>>> t._create(migrate=migrate, fake_migrate=fake_migrate)
>>>> File "/Users/mart/Documents/Aptana Studio Workspace/blueLite/src/
>>>> blueLite/pyUtils/gluon/dal.py", line 1869, in _create
>>>>
>>>>
>>>> Mart :)
>>>>
>>>> On Oct 19, 7:11 pm, mart <msenecal...@gmail.com> wrote:
>>>> > I have recently introduced the web2py DAL to some back-end stuff so
>>>> > that it would play well with the front end (web2py). Although I did
>>>> > trim it down and the amount of files in the gluon folder (I bootstrap
>>>> > for each start of each software build, so size matters) and got rid of
>>>> > some unresolved imports caused by the triming (i don't need web access
>>>> > here, just the dal). So, are you taking about where (path) the .db and
>>>> > tables get created? if this is the case, then I found 2 things:
>>>> >
>>>> > 1) the db and tables don't seem to follow the same rule in that the db
>>>> > can get created just about anywhere, where the tables seem to get
>>>> > created relative to where *db.define_table(tableName,...)* is called
>>>> > (seems to be the default). so depending on where you are in the
>>>> > structure... also, I notice I had to be xtra sensitive with error
>>>> > handling in that, if a previous step failed to lets say do an update
>>>> > or an insert and if I didn't handle that well at THAT moment, then the
>>>> > next time that field was referenced (which caused an exception), it
>>>> > create the entire set of default tables I setup and would do so where
>>>> > ever the module doing the EXECUTE would be. Which lead to look at
>>>> > dal.py
>>>> >
>>>> > 2)so, her, the code can be changed to modify that behavior, and I kept
>>>> > good focus while following the flow of the script, but it is
>>>> > relatively large file, and I didn't take notes as I was reading. But
>>>> > it should be doable. the trick is to isolate the code directly related
>>>> > to 1) the adapter of the of the db your are using and the table/and
>>>> > migration related actions (that's where we see most of the references
>>>> > to the folder housing the tables). I haven't tried yet, and i don"t
>>>> > know if doing this would offend Massimo, so I held back and stuck with
>>>> > being relative to the folders where I generate tables.
>>>> >
>>>> > BTW - i believe this is the code causing your exception, so one of
>>>> > your params is not in line with what's expected ("if not in key") or
>>>> > its type is wrong (just guessing though).
>>>> >
>>>> > for key in args:
>>>> > if key not in [
>>>> > 'migrate',
>>>> > 'primarykey',
>>>> > 'fake_migrate',
>>>> > 'format',
>>>> > 'trigger_name',
>>>> > 'sequence_name']:
>>>> > raise SyntaxError, 'invalid table "%s" attribute: %s'
>>>> > % (tablename, key)
>>>> >
>>>> > hope it helps.
>>>> >
>>>> > Mart :)
>>>> >
>>>> > On Oct 19, 3:37 pm, Bruno Rocha <rochacbr...@gmail.com> wrote:
>>>> >
>>>> > > Somebody knows a trick?
>>>> >
>>>> > > 2010/10/19 Bruno Rocha <rochacbr...@gmail.com>
>>>> >
>>>> > > > I forgot to mention that I tried:
>>>> >
>>>> > > > DAL(....,folder=...) pointing folder="" to the directory where
>>>> .table
>>>> > > > files are, but does not works.
>>>> >
>>>> > > > 2010/10/19 Bruno Rocha <rochacbr...@gmail.com>
>>>> >
>>>> > > > I know DAL was not made for that, but I'm using the DAL in a
>>>> desktop
>>>> > > >> application with PyGTK, and it is working very well :-)
>>>> >
>>>> > > >> It is a simple application that monitors the presence of
>>>> employees in a
>>>> > > >> company and reads small CSV files from a time clock,
>>>> > > >> people has cards that open the gates/doors of the company
>>>> factory, I use a
>>>> > > >> stream to read the track from serial port of time clock,
>>>> > > >> then, I take the information serialized as CSV, I parse and write
>>>> it into
>>>> > > >> SQLite db, after that , the Janitor uses a PyGTK app to access
>>>> that
>>>> > > >> information.
>>>> >
>>>> > > >> already been running for about 6 months, So far everything is
>>>> working
>>>> > > >> fine, but I can not run the automatic migrations.
>>>> >
>>>> > > >> Does anyone know a way to make migration work automatically with
>>>> DAL Stand
>>>> > > >> Alone?
>>>> >
>>>> > > >> I'm importing sql.py I'm connecting with SQLite, setting tables,
>>>> accessing
>>>> > > >> and doing out any crud operation.
>>>> >
>>>> > > >> The only thing missing is to make migration works.
>>>> >
>>>> > > >> I already set migrate='Mytable.table' and I tried with
>>>> migrate=True
>>>> >
>>>> > > >> ----
>>>> > > >> An example of what I have working in my
>>>> >
>>>> > > >> "connect.py"
>>>> > > >> >>> from gluon.sql import *
>>>> > > >> >>> db = DAL('sqlite://timeclock1.db')
>>>> > > >> >>> Track =
>>>> > > >>
>>>> db.define_table('track',Field('regnumber','integer'),Field('action','integer'),Field('timestamp','datetime'),migrate='track.table')
>>>> >
>>>> > > >> "Form_workflow.py"
>>>> > > >> >>> Track.insert(regnumber=123,action=2,timestamp='2010-10-19')
>>>> > > >> 1
>>>> > > >> >>> Track.insert(regnumber=124,action=2,timestamp='2010-10-19')
>>>> > > >> 2
>>>> > > >> >>> db.commit
>>>> >
>>>> > > >> Until here, its ok.
>>>> >
>>>> > > >> But now I am wanting to change the model, and including
>>>> > > >> Field('department')
>>>> >
>>>> > > >> "connect.py"
>>>> > > >> >>> Track =
>>>> > > >>
>>>> db.define_table('track',Field('regnumber','integer'),Field('action','integer'),Field('timestamp','datetime'),
>>>> > > >> *Field('department')*,migrate='track.table')
>>>> >
>>>> > > >> Traceback (most recent call last):
>>>> > > >> File "<stdin>", line 1, in <module>
>>>> > > >> File "/bin/DAL/gluon/sql.py", line 1346, in define_table
>>>> > > >> raise SyntaxError, 'invalid table name: %s' % tablename
>>>> > > >> SyntaxError: invalid table name: track
>>>> >
>>>> > > >> ----
>>>> >
>>>> > > >> If this is not possible, I'll have to create new fields in SQLite
>>>> and then
>>>> > > >> update my model.
>>>> >
>>>> > > > --
>>>> >
>>>> > > >http://rochacbruno.com.br
>>>> >
>>>> > > --
>>>> >
>>>> > >http://rochacbruno.com.br
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> http://rochacbruno.com.br
>>>
>>
>>
>
>
> --
>
> http://rochacbruno.com.br
>
