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
