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

Reply via email to