Question

I’m try to use a lambda to set a default value based on a value in
another table.

Here is my model:

db.define_table('trip_instance', timestamp, sos_table, 
    Field('trip_type_id',  db.trip_type, label='Trip Type', 
       widget=trip_select_widget, requires = IS_IN_DB(db, 'trip_type.id', '% 
       (name)s'), represent=lambda id:db.trip_type(id)['name']), 
    Field('total_slots', 'integer', default=lambda r: 
       db.trip_type(r.trip_type_id)['total_slots']), 

Locally this causes an error that says:

TypeError: <lambda>() takes exactly 1 argument (0 given) 

And on my server (Linode) there is no error but when I try and create
a new trip instance with sqlform the total slots field is pre-
populated with this:

<function <lambda> at 0x7f27684b7140> 

My lambda looks almost identical to the one that works fine for
represent in the trip_type_id field except I’m using the table instead
of the field. Is that what I’m doing wrong?

Answer 1

If you are using a callable (e.g., lambda) for a field default, I do not think it can take any arguments. Defaults are used to pre-populate form fields, so they should not depend on other field values in the record.

An alternative is to use a computed field (though by default they do not appear in SQLFORMs). Another option is to handle the assignment at the form processing stage, possibly via an onvalidation function — something like this:

form.accepts(...,onvalidation=lambda form:form.vars.update(
    total_slots=form.vars.total_slots or
    db.trip_type(form.vars.trip_type_id)['total_slots']))

In the above code, if a value for total_slots is submitted, it is kept — otherwise, a default value is pulled from the trip_type table based on the value of the submitted trip_type_id.

UPDATE:

As noted in the comments, if you include the total_slots field in the form, if the field is left blank when the form is submitted, an empty value rather than the computed value will be stored in the database. To avoid this problem, you could specify an onvalidation function for the form that checks to see if form.vars.total_slots is empty, and if it is, delete form.vars.total_slots. In that case, because total_slots will not be included in the DB insert, the compute function will be called to fill in the value.

If you want to completely avoid doing anything at the form processing stage, one other option might be to creat a custom validator for the total_slots field. The __init__ method of the validator can take request.vars as an argument so the submitted values for the record will be available to the validator when the form is submitted. When the validator is called (i.e., the __call__ method), it can check to see if the value of total_slots is empty, and if so, it can replace it with a value computed via the field’s compute function. With this setup, the standard compute function will handle direct DB inserts, and the validator will handle inserts via forms.

Note, using the validator method, the value of total_slots will be computed based on the values in request.vars, which are the values of the submitted variables before validation. In this case, that shouldn’t be a problem, but more generally, if any of the field validators involve transformations, the values in request.vars will not exactly match the values ultimately inserted into the DB record.