It seems to be a bug that web2py is not reporting the correct error message. It says invalid tablename if it is already defined, yet it should report that the table already exists... I'll send a patch to Massimo.
-- Thadeus On Wed, Oct 20, 2010 at 11:28 AM, mart <[email protected]> wrote: > hum.. interesting... just got what you meant by dal vs sql.... now > that I think of it, Massimo did mention that dal was a 2nd rev of sql > and that it was experimental. but, that said. I have been using dal, > not sql. I did have to tweak a few things to make it work, but in > general, works great for me. > > I have not specified neither migrate nor fake_migrate. I just know > that dal will make use of them when creating table > (t._create(migrate=migrate, fake_migrate=fake_migrate) Note: I think > there is an equivalent t.create (no under score but would have to > check how they differ). Note, about 1/2 the tables I create are > created on the fly, and the table_name will depend on how some > upstream variables get resolved (can change a lot)... > > One mistake I kept making that kept causing exceptions (until my brain > was sufficiently caffeinated) was when creating some Objects (of > whatever type, again on the fly), I kept making the mistake of using a > var name for the table_name, previously used elsewhere where that name > had served to name a new reference to a class (sorry for the > ridiculous sentence (sounds better in french ;)) - I think I meant I > re-used var names). > > myVar = "generated_class" <-- something generates this string > ref_to_class_generated = myVar <-- "a" is just the name > ... > > later instantiate new class > > myVar = name_of_ref_to_class_previously_generated > myVar = initNewObj(data) > myVar.DoStuff() > bla bla bla > > myVar = str(some_object) --> 'className_is_now_a_string' > so later if I did something like this: > tableName = myVar > db.define_table(tableName, > SQLField('name'), > SQLField('value')) > > I got that bad table name exception, then it went through that > migrate,fake_migrate bit. > So I re-use the name but I tag it for the tableName with a '_name', so > they don"t get confused. > I.e. > myVar_name = str(some_object) --> > 'className_is_still_a_string_but_this_worked' > > had no issues since. > > Mart :) > > > > On Oct 20, 11:12 am, Thadeus Burgess <[email protected]> wrote: > > 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 > > > > >
