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 <[email protected]>
> 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 <[email protected]>wrote:
>
>> did you specified both migrate and fake_migrate ?
>>
>> 2010/10/20 mart <[email protected]>
>>
>> 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 <[email protected]> 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 <[email protected]> wrote:
>>> >
>>> > > Somebody knows a trick?
>>> >
>>> > > 2010/10/19 Bruno Rocha <[email protected]>
>>> >
>>> > > > 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 <[email protected]>
>>> >
>>> > > > 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
