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
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.
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
- it will make the structure of the application easier to read in a
single place
- it will make the app faster
- it will be easier to implement without breaking backward
compatibility (and there it will get done)
- it will open the possibility for dependencies to be auto-discovered
and therefore the config-file auto-generated
On Jun 10, 12:53 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
> On Jun 10, 12:37 pm, Doug Warren <doug.war...@gmail.com> wrote:
>
> > That's kind of what i was getting at with my suggestion listed above
> > in some pseudocode.
>
> Right - except for this:
>
> [[for those that "read" all-caps as "yelling" (who the heck thought
> that? CLEARLY not anyone that was alive, or could have worked on a
> TTY machine!!!) --- since I there is NO other way to add EMPHASIS ---
> that is what I am doing with ALL-CAPS: translate it as BOLD when you
> read; and _this_ is my way of adding italics;]]
>
> Right now, gluon/main BLINDLY sets up an execution environment /
> setup for ALL requests by ASSUMING that each request will need ALL
> models;
>
> What is _really_ the first thing called is controller/
> requested_controller()
>
> I am suggesting this is the tip of the bigger problem: that gluon/
> main() assumptions are not functional, no longer live.
>
> That is to say: exec'ing models is the _wrong_ model to begin with.
>
> IF you can (just for the sake of argument) swallow that, then models
> should NOT be the first thing looked at AT ALL:
>
> INSTEAD: controller / function should be called, and (with a
> decorator) it's environment setup _as that controller requests_
>
> (so - forget about the models files being looked at _before_ the
> controller: that is too much like "big brother" deciding for
> controller the execution environment).
>
> As I write this (I _am_ thinking out loud), I am aware that the place
> for Massimo's request.models[] list is, in fact NOT in a separate
> file (exec.py), and NOT in the models folder - rather, at the head of
> the controller file.
>
> For example:
>
> default.py:
>
> request.models[ # you could define all models here, if desired , and
> this would apply to all functions for this file ]
>
> This way, controllers could have utililty files which were not reading
> in anything.
>
> I'll let those worried about "backward compatibility" figure out how
> to read ALL the models, if there is no exec.models....
>
> So - this turns on it's head (appropriately, I think) a core way that
> gluon behaves in setting up for a request (and I think this is a
> needed shakeup).
>
> More discussion, thoughts?
>
> (maybe this should move to the web2py developer's thread?)
>
> - Yarko
>
>
>
> > Let the model try to grab it's required modules if it can't find one
> > it'll just raise an exception and it'll be tried again later.
> > Eventually all dependencies that are solvable will work themselves
> > out...
>
> > (Only I wrote while 1: in the pseudocode, and I meant while
> > delay_process, but that's why it's psuedocode)
>
> > On Thu, Jun 10, 2010 at 10:25 AM, Yarko Tymciurak
>
> > <resultsinsoftw...@gmail.com> wrote:
> > > ... this all _sounds_ great, but for one thing:
>
> > > It places a dependency (an "import" or setup list) FAR AWAY from
> > > where it should be declared!!!
>
> > > This _will_ (sooner or later) become a problem.
>
> > > Why not have something _less global_ (why _one_ config file???), and
> > > more component / containment oriented?
>
> > > Just to shift thinking, consider something like a decorator:
>
> > > @depends_on( massimos_request_array )
> > > @requires_login() # oh - I saw that post about default login; I
> > > need to reply to it also
> > > def my_controller_function:
> > > ...
>
> > > The _only_ problem I see with this is that it implies that [1] the
> > > controller is executed FIRST by default, AND for backward
> > > compatibility, if there is _no_ dependency decorator, then the
> > > implicit would be a "invisible decorator-like" behavior of execing
> > > the entire models folder.
>
> > > This _may_ need more code changes in gluon, but I suggest this would
> > > be worth it.
>
> > > Thoughts?
>
> > > - Yarko
>
> > > On Jun 10, 11:30 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > >> What if I needed two controllers to share the same model? Would I then
> > >> place two definitions in request.models?
>
> > >> Not 0.py that is not a valid python filename. Python modules/variables
> > >> cannot start with numbers.
>
> > >> how about just a simple "exec.py" that gets loaded before everything?
>
> > >> --
> > >> Thadeus
>
> > >> On Thu, Jun 10, 2010 at 11:22 AM, mdipierro <mdipie...@cs.depaul.edu>
> > >> wrote:
> > >> > one we agree with the syntax, this is easy. The main issue is making
> > >> > sure it works with bytecode compiled models.
>
> > >> > On Jun 10, 11:20 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > >> >> Here is my proposal:
>
> > >> >> define the following:
>
> > >> >> request.models=(
> > >> >> ('*','db.py'),
> > >> >> ('*','model1.py'),
> > >> >> ('*','model2.py'),
> > >> >> ('default','model3.py'),
> > >> >> ('default/a,default/b','model4.py'),
> > >> >> )
>
> > >> >> it specifies the order in which models should be executed. For each
> > >> >> row, the first item specifies whether the model should be executed for
> > >> >> all actions (*) for all actions in a controller (default) or only for
> > >> >> specific actions (default/a, default/b). The second item in the model
> > >> >> name.
>
> > >> >> All models not listed would be executed in alphabetical order after
> > >> >> those listed explicitly (backward compatibility).
>
> > >> >> request.models would default to [].
>
> > >> >> there would be a special model (execmodels.py? 0.py?) that would
> > >> >> always be executed before every other model and it may override the
> > >> >> value of request.models.
>
> > >> >> all required code should go in a single place run_models_in() in
> > >> >> gluon/
> > >> >> compileapp.py
>
> > >> >> Massimo
>
> > >> >> On Jun 10, 10:56 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> > >> >> > I like the idea of an execmodels.py file, it could create a list of
> > >> >> > model names to execute.. Not yaml or cfg because that means web2py
> > >> >> > would require yet another library
>
> > >> >> > Massimo, tell me where this code *should* go and I will work on it
> > >> >> > since this is a very important feature to me. Lets draft up a
> > >> >> > specification and design first...
>
> > >> >> > I will make a public google doc located here
>
> > >> >> >https://docs.google.com/Doc?docid=0ActNNXQhkjU-ZGMyajJnbTdfOGZ3Z2IzOH...
>
> > >> >> > everyone can edit this doc
>
> > >> >> > What about requiring models from other apps? (i know apps arn't
> > >> >> > supposed to depend on each other, but it might be a good option to
> > >> >> > add
> > >> >> > so you *can* do it).
>
> > >> >> > --
> > >> >> > Thadeus
>
> > >> >> > On Wed, Jun 9, 2010 at 11:42 PM, mdipierro
> > >> >> > <mdipie...@cs.depaul.edu> wrote:
> > >> >> > > They both make a lot of sense. The former would be much easier to
> > >> >> > > implement and would result in faster code.
> > >> >> > > What do other people think?
>
> > >> >> > > On Jun 9, 11:32 pm, Salvor Hardin <salvor.pub...@gmail.com> wrote:
> > >> >> > >> I'm new to python and web2py, so this might sound crazy
> > >> >> > >> but...here
> > >> >> > >> goes.
>
> > >> >> > >> Noob idea #1
> > >> >> > >> Why not provide an optional "exec_models.cfg" file? If it
> > >> >> > >> doesn't
> > >> >> > >> exist, execute *.py files in alphabetical order found in the
> > >> >> > >> models
> > >> >> > >> folder.
>
> > >> >> > >> This will maintain backward compatibility and give web2py more
> > >> >> > >> flexibility.
>
> > >> >> > >> If exec_models.cfg exists, then exec the files in the order
> > >> >> > >> specified
> > >> >> > >> inside exec_models.cfg. If you want to get fancy, allow
> > >> >> > >> wildcards,
> > >> >> > >> etc. Even better, you can also use exec_models.py or
> > >> >> > >> exec_models.yaml
> > >> >> > >> instead of simple config.
>
> > >> >> > >> Noob idea #2
> > >> >> > >> Provide web2py's version of python's "import" function. Call it
> > >> >> > >> "require(somefile.py)" and provide some web2py convention for
> > >> >> > >> somefile.py to follow. That way, you can have require() detect
> > >> >> > >> and
> > >> >> > >> decide what to do if somefile.py was already executed. Ruby has
> > >> >> > >> "require" and rubygems added their own "require_gem()" function
> > >> >> > >> which
> > >> >> > >> might provide useful ideas so you don't have to reinvent the
> > >> >> > >> wheel.
>
> > >> >> > >> It is late, and these are ideas that surfaced in the mind of a
> > >> >> > >> python
> > >> >> > >> and web2py noob. If you must laugh, do so with compassion. In
> > >> >> > >> the
> > >> >> > >> meantime, I'll try to read at least one python book by next
> > >> >> > >> Monday.
> > >> >> > >> Think Python is free online and looks like a quick one.
>
> > >> >> > >> On Jun 9, 9:32 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > >> >> > >> > My approach is to use
>
> > >> >> > >> > db_blablabla1.py
> > >> >> > >> > db_blablabla2.py
> > >> >> > >> > db_blablabla3.py
> > >> >> > >> > ....
>
> > >> >> > >> > where db_blablabla.py defiles all tables that link each other
> > >> >> > >> > for a
> > >> >> > >> > specific purpose. The different files are independent and
> > >> >> > >> > therefore
> > >> >> > >> > the order of execution is not important.
>
> > >> >> > >> > On Jun 9, 9:20 pm, Thadeus Burgess <thade...@thadeusb.com>
> > >> >> > >> > wrote:
>
> > >> >> > >> > > There are some things you can do to alleviate the situation.
>
> > >> >> > >> > > First, you can name you models so that they execute in the
> > >> >> > >> > > correct order.
>
> > >> >> > >> > > A_db.py
> > >> >> > >> > > B_user.py
> > >> >> > >> > > C_post.py
> > >> >> > >> > > E_tag.py
>
> > >> >> > >> > > That said, I usually try to keep all related models in the
> > >> >> > >> > > same file.
> > >> >> > >> > > In your case you might have
>
> > >> >> > >> > > B_user.py
> > >> >> > >> > > C_weblog.py
>
> > >> >> > >> > > Since post and tag both belong to the same logical set of
> > >> >> > >> > > tables,
> > >> >> > >> > > stick them together in one file. For objects, I also might
> > >> >> > >> > > subset it
> > >> >> > >> > > simpler such as
>
> > >> >> > >> > > C_weblog.py
> > >> >> > >> > > C_weblog_objects.py # contains virtualfield definitions.
>
> > >> >> > >> > > --
> > >> >> > >> > > Thadeus
>
> > >> >> > >> > > On Wed, Jun 9, 2010 at 4:42 PM, mdipierro
> > >> >> > >> > > <mdipie...@cs.depaul.edu> wrote:
> > >> >> > >> > > > No. This the main issue with web2py design. This is the
> > >> >> > >> > > > price we pay
> > >> >> > >> > > > for not having imports
>
> ...
>
> read more »
