The problem is that updates do not involve pulling the existing records from the database into web2py, so web2py doesn't have access to the existing field values (nor does web2py know which fields are needed by the compute function). Also, because computed field values could be different for each record, you cannot simply issue a single database update but instead must iterate over each record and do individual updates. So, for updates to tables with computed fields, we would have to first do the database update, then select all the records in the set, then loop over the records and call update_record on each record. This wouldn't necessarily be needed all the time, so maybe could be triggered via a new "recompute" argument to .update():
db(query).update(field1='newvalue', recompute=True) Anthony On Friday, July 18, 2014 8:47:14 AM UTC-4, Leonel Câmara wrote: > > I'm not comfortable enough with the DAL code base to do this kind of, in > part, architectural change. I would probably change _listify to return both > newfields.values() and the to_compute list instead of computing it. Then > only after updating/inserting would I calculate the compute fields. > > This change would also "fix" another leaky abstraction - you having to > update fields that are not actually being updated just because you need > them in the compute function. > > Doing these changes would probably fix all the problems I see people > having in this user group with computed fields. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
