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:
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,
