>> Mariano Reingart Thanks for your response and practical experience with large system.
I think the problem is clear: In current web2py philosophy the same data model becames valid or invalid based on the order of table definition commands. And if a model is complex, then there is no possibility how to make it valid/ acceptable for web2py. So as long this situation will continue, so long there will be block for more complex projects. The problem will come back again and again. It will be nice, if Massimo(?) could redesign this soon in such way: first create tables/fields in the db object, second turn on constraints in cycle over all tables and over all their foreign keys. Of course for large projects there will be a problem of too many tables and slow execution, especially when structures changes. >> Massimo Di Pierro: >> there is a problem if too many tables are in scope. We need to create >> a mechanisn for conditionally executing models based on the called >> action. Perhaps give models a subfolder structure like in views. Maybe this Massimo's idea is good. There should be always one model (default=db.py) with full database definition, and just this model would support structure migrations. In simple projects we could use this model (same situation as today for all web2py projects), in large projects subfolder models can be defined, which are smaller sub-sets of the whole model - they would not support migration, but they just will (together with controller) prepare data for specific view. However, I don't know, if such system change in web2py would be good. Because who need such something to speed up his model, he can test request.controller and request.function in model and he can conditional call what he need.
