ok, I had time to test. SQLite environment, bug is there for 2.2.1, but is fixed in trunk. For PostgreSQL, it's a different story. I'll quote the official docs on that *
Restricting and cascading deletes are the two most common options. RESTRICTprevents deletion of a referenced row. NO ACTION means that if any referencing rows still exist when the constraint is checked, an error is raised; this is the default behavior if you do not specify anything. (The essential difference between these two choices is that NO ACTION allows the check to be deferred until later in the transaction, whereas RESTRICT does not.) CASCADE specifies that when a referenced row is deleted, row(s) referencing it should be automatically deleted as well. There are two other options: SET NULL and SET DEFAULT. These cause the referencing columns to be set to nulls or default values, respectively, when the referenced row is deleted. Note that these do not excuse you from observing any constraints. For example, if an action specifies SET DEFAULT but the default value would not satisfy the foreign key, the operation will fail.* So, ondelete='NO ACTION' will still raise the error. If you need - as it seems - to simply let the "check" loose if the parent record is deleted, the way to go is either 'SET NULL' or 'SET DEFAULT'. BTW: To exploit SET DEFAULT you can't rely on the default= attribute of the field, that one is valid only inside the DAL. SET NULL works perfectly fine (i.e. your table3 record will have a field2t3 set to NULL, effectively "loosing" the reference to table2.id) PS: you have to let web2py recreate the table because once the table is created, changes to the ondelete attribute will not trigger the COSTRAINT drop and recreation. On Tuesday, December 11, 2012 8:32:11 PM UTC+1, Richard wrote: > > You are right that what I am think, but the doc is not clear. > > I open an other thread about a function that should be trigger on > crud.update in case of deletation with crud.update(..., ondelete=funciton) > > Thanks > > Richard > > On Tue, Dec 11, 2012 at 2:18 PM, Mark <[email protected] <javascript:>>wrote: > >> > > > --
