[web2py] Re: Stand Alone DAL and migrations (again)
well. I disagree. ;-) http://web2py.com/AlterEgo/default/show/215 On 30 oct, 12:42, Thadeus Burgess thade...@thadeusb.com wrote: Just my 2 cents. Using the DAL on anything but web2py is going to be a pain in the ass and a nightmare waiting to happen. This is due to its inherent forced procedural coding style. You can wrap DAL calls as methods, but it just gets really messy. I'm a clean code zealot, so I bet I care more than most. For any kind of software your developing that uses object oriented programming, use a database system that is structured around classes and declarative bases. You will find this is much much much easier to integrate into, for example a wxWidgets program, than the DAL is. -- Thadeus On Sat, Oct 30, 2010 at 7:29 AM, Stef Mientki stef.mien...@gmail.comwrote: On 30-10-2010 12:06, rochacbruno wrote: Look this simple example: http://bitbucket.org/rochacbruno/dal_on_flask/src/tip/dalFlask.py I have a PyGTK app running very well, I will put the code online soon. hi Bruno, one other question, in the gtk application, do you access the database through a local server, or direct through a local disk location ? And in the latter case, how do you specify a hard disk location ? thanks, Stef Em 30/10/2010, às 06:33, Stef Mientki stef.mien...@gmail.com escreveu: Interesting ... as I want to migrate to web2py and want to have some kind of DAL for my desktop applications, this sounds very good. Can you give me some guide lines, how to use the web2py DAL for desktop applications ? thanks, Stef Mientki On 19-10-2010 05:44, Bruno Rocha wrote: 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.
Re: [web2py] Re: Stand Alone DAL and migrations (again)
Its not about can it be used stand alone. Its about how you have to structure your code when you do. The only reason the DAL works well with web2py is because web2py is executed and designed to be functionally coded. I would suggest SQLAlchemy. Its designed with OOP in mind, and offers more features than the DAL. However, Like I said, if your not concerned with using an OOP design, then the DAL Is probably fine. I have been here, done this. I already have wrote wxWidgets applications that attempted to use the DAL standalone. It worked... but I soon learned SQLAlchemy was much better suited for the job. I speak from experience. If all you are doing is one or two models, then DAL is probably is fine. My application of using the DAL standalone contained over 50 models, all interconnected and weaved into each other. I also needed to organize my code and have all of the models split up into their own files. -- Thadeus On Sat, Oct 30, 2010 at 2:07 PM, mdipierro mdipie...@cs.depaul.edu wrote: well. I disagree. ;-) http://web2py.com/AlterEgo/default/show/215 On 30 oct, 12:42, Thadeus Burgess thade...@thadeusb.com wrote: Just my 2 cents. Using the DAL on anything but web2py is going to be a pain in the ass and a nightmare waiting to happen. This is due to its inherent forced procedural coding style. You can wrap DAL calls as methods, but it just gets really messy. I'm a clean code zealot, so I bet I care more than most. For any kind of software your developing that uses object oriented programming, use a database system that is structured around classes and declarative bases. You will find this is much much much easier to integrate into, for example a wxWidgets program, than the DAL is. -- Thadeus On Sat, Oct 30, 2010 at 7:29 AM, Stef Mientki stef.mien...@gmail.com wrote: On 30-10-2010 12:06, rochacbruno wrote: Look this simple example: http://bitbucket.org/rochacbruno/dal_on_flask/src/tip/dalFlask.py I have a PyGTK app running very well, I will put the code online soon. hi Bruno, one other question, in the gtk application, do you access the database through a local server, or direct through a local disk location ? And in the latter case, how do you specify a hard disk location ? thanks, Stef Em 30/10/2010, às 06:33, Stef Mientki stef.mien...@gmail.com escreveu: Interesting ... as I want to migrate to web2py and want to have some kind of DAL for my desktop applications, this sounds very good. Can you give me some guide lines, how to use the web2py DAL for desktop applications ? thanks, Stef Mientki On 19-10-2010 05:44, Bruno Rocha wrote: 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.
Re: [web2py] Re: Stand Alone DAL and migrations (again)
That works now! I just updated with trunk and now migrations are working very nice! I dont know if anything has changed in DAL, but if has, Thank you so much! Next Saturday I am going to talk about DAL and StandAlone DAL on PyCon Brasil Today I talked about MARKMIN, tomorow I will talk about InstantPress and saturday about The DAL.
Re: [web2py] Re: Stand Alone DAL and migrations (again)
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 dont 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
Re: [web2py] Re: Stand Alone DAL and migrations (again)
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 dont 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
Re: [web2py] Re: Stand Alone DAL and migrations (again)
I am using sql.py, but migrations is not working 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.comwrote: 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 dont 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
Re: [web2py] Re: Stand Alone DAL and migrations (again)
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.comwrote: 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 dont 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:
[web2py] Re: Stand Alone DAL and migrations (again)
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 dont 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 thade...@thadeusb.com 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 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
Re: [web2py] Re: Stand Alone DAL and migrations (again)
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.comwrote: 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 dont 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
Re: [web2py] Re: Stand Alone DAL and migrations (again)
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 msenecal...@gmail.com 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 dont 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 thade...@thadeusb.com 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 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,
[web2py] Re: Stand Alone DAL and migrations (again)
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 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.comwrote: 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 dont know if doing this would offend Massimo, so I held
[web2py] Re: Stand Alone DAL and migrations (again)
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
[web2py] Re: Stand Alone DAL and migrations (again)
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 dont 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
[web2py] Re: Stand Alone DAL and migrations (again)
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 dont 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
[web2py] Re: Stand Alone DAL and migrations (again)
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