>>>A good advise, but, not always possible. I am considering to migrate an App in the range of 70-100 tables to web2py and there are tables that are like pillars, belong to several groups (customers, employees, projects,...) How we could manage this >>>shared tables? >>> >>>Also sometimes its hard to determine an order for the tables to avoid referencing a "still undefined" table. >>> >>>There is another type of large applications, enterprise level with hundreds or thousands of tables. The approach of multiples apps sharing same database is useful, but how could we solve the division of tables in apps, is it better to define the >>>model in one place and "import" the required tables on the apps?
This is why I prefer Flask + SQLAlchemy. -- Thadeus 2010/11/14 José Ignacio Hurtado <jose.i.hurt...@gmail.com> > A good advise, but, not always possible. I am considering to migrate an App > in the range of 70-100 tables to web2py and there are tables that are like > pillars, belong to several groups (customers, employees, projects,...) How > we could manage this shared tables? > > Also sometimes its hard to determine an order for the tables to avoid > referencing a "still undefined" table. > > There is another type of large applications, enterprise level with hundreds > or thousands of tables. The approach of multiples apps sharing same database > is useful, but how could we solve the division of tables in apps, is it > better to define the model in one place and "import" the required tables on > the apps? > > Jose. > > 2010/11/14 mdipierro <mdipie...@cs.depaul.edu> > > I agree that there are things we can improve in web2py. >> >> Yet, if a complex application have many pieces that are untangled, the >> import mechanism does not necessarily help you. The solution is trying >> to design components that are relatively independent. If you can do >> this, web2py does not bet in the way. For example, you have 100 tables >> functionally grouped in ~10 and all they need to share is >> authentication, you may want to separate the functions in 10 different >> web2py applications (all sharing one database, each defining only the >> tables it needs, and sharing one session cookie). This modular design >> solves lots of problems. >> >> I have heard of people who have developed complex applications in >> Django (which uses the import you suggest) and run into problems >> because they were using more ram than needed since all modules were >> always imported. In web2py controllers are executed only when called >> and if you make many small controllers you save lots of memory. >> Controllers than then import the modules they need and only those. >> >> Massimo >> >> On Nov 13, 7:28 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >> > The biggest contributing factor is that web2py is executed and not >> import. >> > The coder must always be sure to align objects and database in the >> correct >> > order, including any auxiliary functions, class mappings, queries. >> He/she >> > has to worry about the "order" of everything. Sometimes you can't have >> such >> > order for complex systems. I think an import based system solves this in >> > that the import statements declare the order instead of the physical >> > location of the code doing that. >> > >> > -- >> > Thadeus >> > >> > On Sat, Nov 13, 2010 at 2:49 PM, Jason Brower <encomp...@gmail.com> >> wrote: >> > > These are encouraging. >> > > In large deployment I mean it in the most external sense of it. >> Facebook >> > > is big, myspace is big, those kinds of object were what I was aiming >> for. >> > > And with Massimo's comment about the database size. I think your >> right, the >> > > framework does become less relavent. In what ways in a large codebase >> > > making web2py code messier and is there a solution to it in another >> > > framework? >> > > BR, >> > > J >> > >> > > On Sat, 2010-11-13 at 11:48 -0600, Thadeus Burgess wrote: >> > >> > > What is large deployment? >> > >> > > Is it a large codebase that you must manage for an internal dashbaord, >> or >> > > just alot of users/database io that needs to scale out for worldwide >> access? >> > >> > > If its the first case, web2py can get really complicated in dealing >> with >> > > lots of models and difficult to manage in an efficient manner. The >> larger >> > > your codebase the messier web2py apps will become. In the end, this >> would >> > > ultimately be up to the preferences of you and your team and what your >> > > willing to put up with. >> > >> > > In the second case, framework hardly matters at that point. Disqus >> uses >> > > django, facebook uses php, reddit uses pylons, myspace uses >> coldfusion, >> > > microsoft uses asp, oracle uses java. Its always the database that >> becomes >> > > an issue regardless of programming language or web framework. >> > >> > > -- >> > > Thadeus >> > >> > > On Sat, Nov 13, 2010 at 10:53 AM, mdipierro <mdipie...@cs.depaul.edu >> > >> > > wrote: >> > >> > > I agree with Villas. The larger the development the more the database >> > > becomes the bottleneck and the framework irrelevant. >> > >> > > Massimo >> > >> > > On Nov 13, 8:35 am, villas <villa...@gmail.com> wrote: >> > > > Hi Jason >> > >> > > > I guess you have to define 'large deployment' first of all. Number >> of >> > > > records and size of DB? Number of concurrent users? Large data model >> > > > or number of forms etc? Number of servers -- or replication? >> Global >> > > > coverage? >> > >> > > > In principle I don't think there's any reason why Web2py would be >> > > > worse than other frameworks. Usually it is much better! As an >> > > > example, I think deploying to the Google App Engine should be able >> to >> > > > scale sufficiently for everything but extreme cases :) >> > >> > > > If you specify more about what you wish to achieve this group may be >> > > > able to give more specific advice how best to organise your project. >> > >> > > > -D >> > >> > > > On Nov 13, 7:12 am, Jason Brower <encomp...@gmail.com> wrote: >> > >> > > > > I love web2py and it's the only framework i feel i am fully >> capable to >> > > do or learn to do quickly. >> > > > > However, I remember see that this framework is intended for small >> to >> > > medium sized deployments. Is this true? What is it that stops us from >> larger >> > > deployment? Should i pickup django because i may need it? >> > > > > Regards, >> > > > > jb >> > >> > >> > > > > -- > Un saludo, > > José Ignacio Hurtado López >
