Flask has a clever mechanism that web2py also uses internally in DAL. It partially addresses the problem:
Consider this example: http://github.com/mitsuhiko/flask/blob/master/examples/flaskr/flaskr.py Consider the action "login". request is a global object that acts as a proxy. Any attribute of request gets mapped into the corresponding attribute of an object that exist only for the current thread. Yet you see that all code outside functions is executed only once when the web server starts and before any request arrives. All code that accesses the thread local proxies (request, session, etc) is in functions and they must be called explicitly. web2py allows to have code in models that is not in any function therefore you do not need to call it. We can think of it as app level global variables. This is the point I was making before. We use something similar to thread local vars inside the DAL since connection objects are thread locals. We just do not user a proxy class but an dictionary mapping between thread_id and connection objects. Anyway, the idea of thread local proxy is really nice and I will think if we can take advantage of it. Massimo On Jun 10, 7:03 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > This code MUST be executed. There is no way to import it because > > request.client only exist when the request arrives and we do not want > > to re import modules on every request. > > Flask accomplishes this perfectly by placing the request in a context > thread local. It only exists the the thread local when a request > actually arrives. > > So from flask import request will fail if there is actually no request! > > I am learning more about thread locals at the moment, but it seems > reasonable enough and it works. > > -- > Thadeus > > On Thu, Jun 10, 2010 at 4:53 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > The conclusion is right but it is more complicated than that. This is > > not a syntactical issue. > > > Let' say in a model we have: > > > db.define_table('a',Field('b',default=request.client)) > > > This code MUST be executed. There is no way to import it because > > request.client only exist when the request arrives and we do not want > > to re import modules on every request. > > > The easiness comes from the fact that you can code assuming there is a > > client while in other frameworks you need to be careful and wrap > > everything into functions that eventually will be called when the > > request arrives and the request is passed around explicitly. In all > > other frameworks, the imports are resolved before an http request > > arrives, not after. This is why for example, they have issue with > > multiple database connections, client dependent database connections, > > real time migrations, etc. Moreover, as a result they need to monitor > > py files for changes are reload them when changes occur. This > > mechanism works ONLY for pure-python web servers and not with apache > > for example. Moreover this is subject to all the reload caveats > >http://docs.python.org/library/functions.htmlabout old global > > variables being retained on reload in the module __dict__ (this may > > cause memory leaks and data leaking from one session to another thus > > causing security issues). We make a clean exec for every request and > > we have no memory leaks and no data pollution as well a clean syntax. > > > There will be no import of models in web2py or it will not be web2py > > any more. > > > This can be reassessed in web3py but as I stated before: IF there is a > > web3py for me to be interesting it has to be completely different. It > > may not even be in Python. Perhaps we should look into Cobra (http:// > > cobra-language.com/). > > > Massimo > > > On Jun 10, 3:44 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > >> This is what I desire from this > > >> Web2py applications to be importable python modules > >> Along with [A] your models immediately become python modules that you > >> can import. This solves my need to share models between web2py apps.' > > >> Web2py has a Top down approach, where other frameworks use a down-up > >> approach. Meaning, web2py executes the models THEN looks at the > >> request, determines the controller and executes it, then executes the > >> view. Everyone else does the down-top approach, where the request > >> comes in, it goes to the controller, the controller decides what > >> models to IMPORT and then executes itself and even decides what view > >> to return if any! > > >> This is what the discussion has turned into, a design pattern, web2py > >> can never satisfy the down-top approach because of backwards > >> compatibility. Perhaps web3py. > > >> -- > >> Thadeus > > >> On Thu, Jun 10, 2010 at 3:24 PM, Yarko Tymciurak > > >> <resultsinsoftw...@gmail.com> wrote: > >> > On Jun 10, 1:17 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > >> >> If we are going to work on this we may as well solve a different > >> >> problem. > > >> >> Executing models take time. If you have 500 tables each defined it its > >> >> own file, it takes lots of time. Yet not all actions need all tables > >> >> so we may want to implement a dependency not just among models but > >> >> among actions and models so that not-needed models are not executed. > > >> >> If the dependencies are expressed in the model files themselves they > > >> > ... I assume you meant to say "...in controller files..." > > >> >> still needs to be executed (or at least bytceode compiled) to be > >> >> resolved and that defies the purpose. > >> >> Moreover this would be similar to the python import mechanism (from a > >> >> user prospective) and thus an example of reinventing the wheel. > > >> > ... if I am following you, then why do we not just import the needed > >> > models? I mean, really, seriously - why the need to exec? > > >> > It seems like that is a question on the table. > > >> >> Having a centralized place where these dependencies are expressed has > >> >> advantages: > >> >> - sets us a apart from everybody and we do not need to reinvent the > >> >> wheel > > >> > Global variables in FORTRAN had proponents too - but the need to > >> > manage complexity drove a different structure in programming. > >> > (That is to say, I am not seeing, am challenging that there are _any_ > >> > REAL advantages to centralized dependency management;) > > >> > ==> "set us apart" is not any kind of advantage, if it does not > >> > provide tangible benefit. (that is, benefit may drive what sets > >> > web2py apart, but making "set apart" a motive is not beneficial in and > >> > of itself - this should be very clear). > > >> > If there is a current wheel that is useful, use it. > > >> > $ python > >> >>>> import this > > >> > one way is better; if there is something that currently solves the > >> > problem, use it (don't 'reinvent the wheel'; _and_ don't look for > >> > problems as an excuse to invent a wheel) > > >> >> - it will make the structure of the application easier to read in a > >> >> single place > > >> > ... I don't agree, don't see this as beneficial; harder to maintain; > >> > related information scattered; > > >> >> - it will make the app faster > > >> > ... this is not a benefit - it is a goal; you are implying that > >> > centralized models are the only way to make an app faster; I'm not > >> > buying; I don't think that's true at all. > > >> >> - it will be easier to implement without breaking backward > >> >> compatibility (and there it will get done) > > >> > .... simplicity of implementation is a benefit to _you_; but (while > >> > that may be important to you), simplicity to implement applications > >> > (since it happens more frequently) is first in line; _then_ > >> > simplicity of implementation, practicality; > > >> > .... I don't see this as a benefit of central place; > > >> >> - it will open the possibility for dependencies to be auto-discovered > >> >> and therefore the config-file auto-generated > > >> > ... actually, you could generate (if that were the most practical way) > >> > a central dependency list from local declarations (which is how > >> > Windows Registry works); > > >> > I don't see this is a benefit of "central place", rather a practical > >> > consideration. > > >> > ... this is beginning to feel like an old tet-a-tet. > > >> > ...
