no, tasks are not executed in a normal request/response cycle, so ther's no
user, session, etc.
You can pass the current user as an argument and adjust your models/modules
to take that in consideration
e.g.
queue_task(that_task, [auth.user_id])
PS: check out the lazy_tables argument, it's usually pretty fast even with
a lot of tables. that being said, if you have 1k tables around it's best to
load them dinamically (given that your "lookup and build" function takes
less than building 1k lazy tables).
On Wednesday, May 8, 2013 8:50:53 PM UTC+2, DeanK wrote:
>
> I just sort of figured it out. And yes i'm sorry i didn't give enough to
> go on.
>
> The key seemed to be in the method get_user_allowed_projects. It is in a
> module that is imported into the a model file. It uses
> current.auth.user_groups and some database tables to check project table
> permissions for the user and stores it in the session. I realized that the
> session is bogus and therefore forced this to update but it still didn't
> work. Then i realized that current.auth.user_groups was empty when run on
> the scheduler, which resulted in permission to 0 tables which resulted in 0
> tables getting defined which resulted in my error...
>
> Do tasks run in the scheduler have no concept of the user who scheduled
> them?
>
> My current work around is if the model is getting executed in the
> scheduler (i check this by looking at the length of request.env...is there
> a better way?) then I just define all the tables. Since it's running on
> the scheduler a little overhead isn't going to kill things, but it's not
> ideal.
>
>
>
> On Wednesday, May 8, 2013 2:37:55 PM UTC-4, Niphlod wrote:
>>
>> the task definitely runs in a fresh environment, but as it stands your
>> explanation doesn't give me enough details to build a proof of concept.
>> if you have some - even weird - code that basically looks up the
>> "projects" table to build definitions of tables, then if that piece of code
>> is executed in the task you should be perfectly fine.
>> The only thing I can reproduce is that a task defined as
>>
>> def mytest_models():
>> db.define_table('whatever',
>> Field('afield')
>> )
>> db.whatever.insert(afield='foo')
>> db.commit()
>>
>> works as intended.
>>
>> On Wednesday, May 8, 2013 6:02:07 PM UTC+2, DeanK wrote:
>>>
>>> So one of my model files is somewhat unique (and possibly a bad idea)
>>> and causing me problems...I'll try to describe things the best I can.
>>>
>>> My application creates tables dynamically based on user input. To stop
>>> web2py from defining all the tables on every request (which can be a lot in
>>> the whole app, but only 10ish per user), I check which tables the user has
>>> access to and define only those. This is done by looking at a table
>>> (projects) where each record specifies other tables that exist (the project
>>> support tables).
>>>
>>> The issue i'm having is the user fills out a form using smartgrid. In
>>> the oncreate callback I update the projects table which essentially
>>> specifies new tables. These new tables are not defined unless the model
>>> runs again. I know this will happen on a refresh, but is there any other
>>> way to force the models to update?
>>>
>>>
>>> If I then submit a job to the scheduler that references one of these
>>> "new" tables I get this error:
>>>
>>> 'DAL' object has no attribute 'test_project_proj'
>>>
>>> Where test_project_proj one of the support tables that should have been
>>> defined (in the model snippet below project.project_table =
>>> 'test_project_proj') .
>>>
>>>
>>>
>>> Example of key part of the model:
>>>
>>>
>>> user_allowed_ids = get_user_allowed_projects(False) for project in db(db
>>> .projects.id.belongs(user_allowed_ids)).select():
>>> db.define_table(project.project_table,......)
>>> db.define_table(project.block_table,......)
>>> db.define_table(project.metadata_table,......)
>>>
>>>
>>>
>>>
>>> I thought that when a job runs on the scheduler it re-runs all the models,
>>> so i don't understand why the task isn't seeing the new tables. Thoughts?
>>> Thanks
>>>
>>>
>>>
>>> Dean
>>>
>>>
>>>
>>>
>>>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
