Disabling migrations is the first thing everyone should do when the application is put into production, regardless of the number of tables. Close second would be to compile the application. Anyway, there is plenty of threads addressing optimization questions.
If editing trough a web interface is a must and there is a question of keeping the files tidy (ie. split according to function, etc.), why not split this humongous db.py temporarily and then join the files back together when the project is finished? Go with something like db_00.py, db_01.py, etc. Just a thought. Regards, Ales On Tuesday, August 13, 2013 3:58:29 AM UTC+2, Luca wrote: > > I generally like to split things according to function, and I don't like > files much larger than 1000 lines, so I would split, but this is a matter > of style. > Aside from this, you might want to see if you can reorganize your tables > into fewer ones... > One other thing is that I wonder if it would help to set > migrate_enabled=False in your db.py, and only set it to True when you need. > Otherwise, for 100 tables, the size of the information that needs to be > checked to determine whether a migration is needed could be large. > > Luca > > On Sunday, August 11, 2013 6:45:08 AM UTC-7, Alex Glaros wrote: >> >> Is the size of a model or controller file a reason for breaking it into >> smaller files? >> >> my default/db.py file has over 100 tables and sometimes editing it is >> slow. Is editing speed by itself a reason for splitting up the file? >> >> thanks, >> >> Alex >> > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
