db.define_table('my_table',
Field('a_field', indexed=True),
Field('b_field', 'int')
)
db.define_table('my_table',
Field('a_field', 'int'),
Field('b_field'),
Field('c_field'),
indexes=['a_field', ('b_field', 'c_field')]
)
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
db.my_table.add_index('field_a')
db.my_table.drop_index('field_a')
make speech: web2py-developers@googlegroups.com
unsubscribe: web2py-developers+unsubscribe@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-developers+unsubscribe@googlegroups.com.
We can start development on just these 2 commands, but I think that, sooner or later, we should deal with the migrations engine.pyDAL provides automatic migrations by design. I wouldn't propose the index feature inside table definition IF migrations weren't automatic. If migrations on pyDAL were supposed to work with specific commands, then having indexes ONLY with specific commands make sense to me. but IMHO, since pyDAL make migrations for me, why is not supposed to migrate indexes as well?
Anthony you are right, but consider this:- I issue a db.mytable.create_index() which create a migration- table definition doesn't have any info regarding indexes- when I start application with the created index, how will the migration engine knows if it should keep or drop the index since the table definition says: no index at all?
--
Is the order of definitions going to be important?AFAIK in SQL the order is respected always. But for instance with DAL references are deferred.IMHO it should be better to would avoid deferral with indexes thus allowing to use expressions (on already defined entities).db.create_index(db.table1.field2)Just a curiosity about syntax: why "create_index" when do not have "create_table"?
db.table1.create_index(...)