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 don"t
>> > know if doing this would offend Massimo, so I held back and stuck with
>> > being relative to the folders where I generate tables.
>> >
>> > BTW - i believe this is the code causing your exception, so one of
>> > your params is not in line with what's expected ("if not in key") or
>> > its type is wrong (just guessing though).
>> >
>> > for key in args:
>> > if key not in [
>> > 'migrate',
>> > 'primarykey',
>> > 'fake_migrate',
>> > 'format',
>> > 'trigger_name',
>> > 'sequence_name']:
>> > raise SyntaxError, 'invalid table "%s" attribute: %s'
>> > % (tablename, key)
>> >
>> > hope it helps.
>> >
>> > Mart :)
>> >
>> > On Oct 19, 3:37 pm, Bruno Rocha <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
>> >
>> >
>>
>
>
>
> --
>
> http://rochacbruno.com.br
>
