I think that as long as you develop good code, choose a good interpreter, use assynchronous requests as adequate and good caching, you shouldn't have many constraints other than the database. There, I think there is no work-around. You have to make specific/manual DB handling for each DBMS to assure good scalibility. Out of the box, there aren't many things like this that do much better.
On Nov 14, 3:41 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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