I apologize for the lack of responsiveness. Some of us have been busy
attending with PyCon Argentina and PyCon Brazil.
Everything you propose is sensible. cron @reboot should work but other
users have reported problems with it. I believe there is an open ticket
about it.
I will look at this asap. Even if cron will be phased out, it remains the
best way to run something @reboot.
Massimo
On Thursday, 29 November 2012 08:41:49 UTC-6, Magnitus wrote:
>
> I'd be curious to know if the lack of feedback on this thread so far is
> due to the devs being incredibly busy or web2py lacking a genuine working
> mechanism to execute scripts that have access to the models at startup only.
>
> I've tried a lot of permutations for setting a script at the start with
> cron and I'm now convinced that the functionality is either broken or so
> obscure that most non-devs users that rely on the documentation alone won't
> be able to make it work (at least, not without a major head ache).
>
> Besides, it seems from the documentation that cron is being phased out
> anyways, so I'm thinking it would be nice to provide some sort of hook for
> users to insert a script at startup with access to the models instead.
>
> Inserting "from gluon import *" in the module won't work either since the
> db handles are not defined in gluon, but in the models.
>
> I'm guessing that maybe the entire database definition could be moved to a
> module instead (I'd have to reflect on all the implications of this though
> it would definitely increase the performance at the cost of having to
> reboot when you want to modify the db's structure), but that's not the
> default out of the box architecture.
>
> Either way, inserting the script into a module that is included in a
> controller is not a 100% satisfying solution since the script is actually
> executed on the first page request and not really at startup.
>
> On Wednesday, 28 November 2012 12:55:00 UTC-5, Magnitus wrote:
>>
>> After some reflection, I suppose I could write a wrapper script that
>> first runs python web2py.py --import_models --shell=<MyController>/default
>> --run="<My Script>" and then starts web2py normally when using web2py
>> standalone.
>>
>> That is one workaround.
>>
>> On Wednesday, 28 November 2012 11:19:01 UTC-5, Magnitus wrote:
>>>
>>> Hi gents,
>>>
>>> I have been populating my databases with groups (for access control)
>>> manually for a while and then, switched to running a script that does it,
>>> though I still run the script manually in the web2py context.
>>>
>>> Now, I'd like to programmatically implement this in a sensible way (in a
>>> way that runs by itself and doesn't need human intervention at all).
>>>
>>> Obviously, you could just put the logic that does this in a model, but I
>>> don't like the idea of needlessly increasing the size of my models with
>>> this or running the logic to check the existance of and generate groups for
>>> each request.
>>>
>>> Another alternative would be to put the logic in a module that would be
>>> imported (with the idea that it would run on the first import which is done
>>> only once), but then imported modules don't have access to the web2py
>>> objects (notably, my database handle) unless you pass them on as parameters
>>> which you cannot do in a module's global scope when it is first included.
>>>
>>> This leaves me with cron and running it as a cron job at boot time.
>>> However, it isn't working.
>>>
>>> I tried running my script using the web2py context (ie, python web2py.py
>>> --import_models --shell=<MyController>/default --run="<My Script>") and it
>>> ran fine and generated the db entries I wanted.
>>>
>>> Then, I started my web2py execution with cron activated (ie, python
>>> web2py.py -Y).
>>>
>>> I tried the two varations portayed in the example for the crontab
>>> ("@reboot * * * * root *applications/<My App>/cron/Generate_groups.py" and
>>> the shorter "@reboot root *applications/<My App>/cron/Generate_groups.py).
>>>
>>> And yes, my db transactions end with a db.commit().
>>>
>>> I've been banging my head against this for two hours and while I'm sure
>>> whatever is wrong with this will come to me over time, this is definitely a
>>> case of sooner would be better than later.
>>>
>>> Insights would be appreciated.
>>>
>>
--
