This is a nice solution, and clever, thanks!
The upside (compared to postgres locks, as discussed above) is this works
for any database. The downside is it creates a whole new table.
On Thursday, July 5, 2012 2:49:36 PM UTC-7, nick name wrote:
>
> This might have been solved in this week, but in case it wasn't:
>
> You're tackling a general database problem, not a specific task queue or
> web2py problem. So you need to solve it with the database: set up another
> table to refer to you the task table, such as:
>
> db.define_table('tasks_that_were_set_up',
> Field('name', 'string', unique=true),
> Field('scheduler', db.scheduler_task, notnull=True, required=True,
> unique=True, ondelete='CASCADE'),
> )
>
> Make your insert code insert a task to this table as well:
>
> try:
> rid = db.scheduler_task.insert(name='task7',....)
> db.tasks_that_were_set_up.insert(name='task7', scheduler=rid)
> print 'Task was just added to db'
> except db.integrity_error_class():
> print 'Tasks were already in db.... */
>
> Now, if the task gets removed from the scheduler_task table, because of
> the cascading on_delete (which is the default - I just put it there for
> emphasis), the record in tasks_that_were_set_up will be removed as well.
> And otherwise, because of the unique constraint, the insert to
> tasks_that_were_set_up can only succeed once -- and thanks to the
> transaction nature -- therefore so does scheduler_task.insert.
>
>
