I would try this: trackTable = track.table (just something that is clearly different
where trackTable is just a string. I'm a little paranoid when coding, so I would probably add something to check the type, then a str(tackTable)... but, that's probably over doing it ;) I think the issue really just the name, where this would be fine in any py script, here we have no control over how the table_name gets validated (unless as mentioned above, you change the code to change the behavior), and we know that the code has a strong insistence on uniqueness for the table names it creates. On Oct 20, 12:11 pm, Bruno Rocha <[email protected]> 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 <[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
