How will the exec_models.py be formatted
Could it potentially be executed in an environment given a list, and
append or overwrite this list with the model definitions
exec_models = [
'settings.py', 'db.py', 'auth.py', 'tag.py', 'post.py',
'comments.py', 'menu.py', 'other.py',
]
Wildcards
You should be able to specify a wildcard that would execute every
remaining models in alpha order.
exec_models = ['settings.py', 'db.py', '*']
The default exec_models.py file would contain a simple ['*'] from now on.
Models from other applications
It would be nice if you could execute models from another application.
This leads to some issues such as
1) What if the other apps models overwrite some settings?
Think of a situation you could have two sites, one public signup site,
and a backend dashboard.
You could do the following
exec_models = ['backend.settings.py', 'backend.db.py', 'pages.py']
It will execute settings.py existing in the backend application, say
this settings.py declares a DAL instance
that then the rest of the current app will use. This way if two apps
use the same database connection
this theoretically allows a KISS principle by only having to write the
database settings once, and the common
tables once.
--
Thadeus
On Thu, Jun 10, 2010 at 12:17 PM, Yarko Tymciurak
<resultsinsoftw...@gmail.com> wrote:
> 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).
>
> ==> Why? Your reason for adding this requirement here is not
> evident.
>
> I thought the original suggestion: that backward compatibility is
> accomplished, and current order of exectution actuated in the
> _absence_ of an exec.py (or whateve the name ends up being).
>
>>
>> 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 of models.
>>
>> > >> > > > On Jun 9, 4:21 pm, Binh <btbinht...@gmail.com> wrote:
>> > >> > > >> Hi,
>>
>> > >> > > >> I am trying to create an orm setup like in ruby on rails with
>> > >> > > >> the DAL.
>> > >> > > >> I have a user, post, and tag model.
>> > >> > > >> A user has many posts.
>> > >> > > >> A tag belongs to a user.
>> > >> > > >> A post has and belongs to many tags.
>> > >> > > >> A tag has and belongs to many posts.
>>
>> > >> > > >> I have 4 separate files in my models folder: db.py, user.py,
>> > >> > > >> post.py,
>> > >> > > >> and tag.py
>> > >> > > >> db.py contains the db connection and mail configurations.
>> > >> > > >> The respective model files define the table structure and have a
>> > >> > > >> class
>> > >> > > >> named after the model to implement virtual fields.
>>
>> > >> > > >> I noticed that defining the tables with relationships in the
>> > >> > > >> separate
>> > >> > > >> files does not work properly.
>> > >> > > >> The model files would load which appears to be in alphabetical
>> > >> > > >> order.
>> > >> > > >> So, my db.py would load first and then post.py which fails.
>> > >> > > >> post.py fails to recognize the table definition in user.py, so it
>> > >> > > >> cannot define the belongs to relationship.
>>
>> > >> > > >> Is their anyway to setup a model file to import all the other
>> > >> > > >> models
>> > >> > > >> without the hassle of file load order and possibly import order
>> > >> > > >> which
>> > >> > > >> rails does implicitly?
>
