nope. what it really happens is that scheduler module "register itself"
under the current namespace. When you do -K , it just spawns a process that
executes "from gluon import current;current._scheduler.loop()" in the
context of the app.
Given that DAL under the hood represents a connection, and
Thanks Niphlod, It works!
I added
self.db_thread.executesql("set search_path to scheduler, auth, ... ;")
in gluon/scheduler.py
after the self.db_thread = DAL( line and before the
self.define_tables( ... line
I am aware of the fact that it is not supported, but the database uses a
strict s
the scheduler though doesn't know anything about the search path when it
rebuilds its own model... that's why setting search_path is undocumented ^_^
you can try fiddling with the source of the scheduler (along these lines
https://github.com/web2py/web2py/blob/master/gluon/scheduler.py#L948) to
Hi Niphlod,
Normally i just put a record in the scheduler_task table with appadmin.
That works fine (no errors), but nothing happens because the scheduler
worker is not running.
In db.py the database schema is set via db.executesql("set search_path to
auth,scheduler, ... ;")
In case migrate i
what happens when you try to queue a task from the app ? AFAIK I'd be eager
to know how can it work if there is no "public" schema, unless you tinkered
with scheduler's table definitions
On Friday, June 3, 2016 at 4:57:23 PM UTC+2, Bart wrote:
>
> Addition:
>
> I am using several schema's in the
Addition:
I am using several schema's in the postgres database.
The scheduler tables are in schema 'scheduler'
Schema 'public' does not exist.
Can this cause the problem?
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
6 matches
Mail list logo