It's not the scheduler code that has changed/improved, it's a major change in DAL code that needed some tune-ups. That same change in DAL needs to be tested throughly, but I think nightly builds will come soon.
On Sunday, October 7, 2012 8:44:04 PM UTC+2, Adi wrote: > > Oh Niphlod :) No, I wasn't aware of that... > > In that case it works as expected :) I created a new db, and introduced a > return value, which caused a record into into scheduler_run with status > "COMPLETED", and additional details in "result" field. This is perfect... > > Thank you very much for scheduler. It's an instrumental part of our > application. > > When do you think this will go into a nightly build, so we can test it in > production? > > Thanks, > Adnan > > On Sun, Oct 7, 2012 at 2:16 PM, Niphlod <nip...@gmail.com <javascript:>>wrote: > >> are you aware that if your task doesn't return nothing and doesn't go >> into exception the new scheduler will erase the scheduler_run record ? >> >> >> On Sunday, October 7, 2012 7:57:52 PM UTC+2, Adi wrote: >> >>> The task executed properly, marked status "COMPLETED" in scheduler_task >>> table, but didn't insert a record into scheduler_run table. I will create >>> a new mysql database and let you know if the problem is there... >>> >>> >>> On Sun, Oct 7, 2012 at 2:12 AM, Massimo Di Pierro <massimo....@gmail.com >>> > wrote: >>> >>>> Can you please check the latest trunk and let us know if the problem >>>> has gone? >>>> >>>> >>>> On Friday, 5 October 2012 19:39:50 UTC-5, Adi wrote: >>>>> >>>>> Yes, new application was using the existing database, so fixing broken >>>>> migration fixed the problem of not executing task. Now it executed and >>>>> marked status as COMPLETED. The problem with scheduler_run table stayed >>>>> the >>>>> same. Status: FAILED, and traceback looks as bellow: >>>>> >>>>> Traceback (most recent call last): >>>>> File "/Users/adnan/web2py209/gluon/****scheduler.py", line 203, in >>>>> executor >>>>> _env = env(a=a,c=c,import_models=**True**) >>>>> File "/Users/adnan/web2py209/gluon/****shell.py", line 134, in env >>>>> sys.exit(1) >>>>> SystemExit: 1 >>>>> >>>>> >>>>> >>>>> On Friday, October 5, 2012 6:59:04 PM UTC-4, Niphlod wrote: >>>>>> >>>>>> ok, the problems seems to be related to migrate, migrate_enabled and >>>>>> fake_migrate_all. Can you try removing those from the db connection just >>>>>> to >>>>>> try it out ? >>>>>> >>>>> -- >>>> >>>> >>>> >>>> >>> >>> >>> -- >> >> >> >> > > > > -- > > Thanks, > Adnan > > video: http://vimeo.com/24653283 > > > --
