Delete instance table when deleting the record in the main referring table

[biostatUniBS]

Let's assume we have a main table called VISIT. Within VISIT I insert an INSTANCE TABLE called DRUGS: every VISIT (repeatable instrument) I can add 1 or more drugs that are repeating instances of the INSTANCE TABLE.

Eg: Visit 1 -> drugs: 1, 2, 3

Now, I can open the INSTANCE TABLE (pop-up) and edit, delete, add instances

Let's assume I want to delete the whole visit: I open the VISIT instrument and delete the instance. At the moment though the connected instances in the INSTANCE TABLE (DRUGS) are not deleted. So, if VISIT was instance number 1, the DB will still have instances in DRUGS referring to VISIT instance number 1, that was deleted. Once I enter a new VISIT instance, that would be 1 and it would have associated the residual INSTANCE TABLE. But that would be wrong.

So, a desired behaviour would be that once the main instrument instance referring to an iNSTANCE TABLE is deleted, the corresponding instances in the INSTANCE TABLE should be removed to.

Any hint

Stefano

[lsgs]

Thanks for raising this Stefano (@biostatUniBS). So you're talking about a cascading delete functionality, where if you remove an instance that has been explicitly related to instances from another repeating form then those related instances are also deleted.

I can certainly see the utility of that in those scenarios (that appear to be quite common) where people are using that @INSTANCETABLE_REF= function, so it would be good to implement. It would need some careful consideration about how it would work in the user interface though - making it very clear to the user that deleting this one form will cause those others to be deleted also...

[biostatUniBS]

Thanks @lsgs! Right on the spot!

When would be that the "cascading delete" is not the desired behaviour? If you use @INSTANCETABLE_REF= it means you create a connection/dependence between the nesting table and the nested one. Deleting the nesting table and letting the nested one alive sounds weird. Maybe adding a @INSTANCE_DELETE function to guide this behaviour? The designer is in charge of deciding for the wanted behaviour, no need to provide such information to the user...I guess...

[biostatUniBS]

@lsgs any luck looking into the issue? ;-)

Ciao!

[lsgs]

I've been thinking about @INSTANCETABLE_REF recently, and I do like the idea of adding an extra option - @INSTANCETABLE_REF_CASCADEDELETE, or something like that. I checked and the redcap_save_record() hook is called when deleting a form, so it would be possible to check whether there are suitably tagged instance tables on the form being deleted. I've added this to my to-do list...

[biostatUniBS]

@lsgs, that would be a great addition. I hardly imagine using INSTANCETABLE without allowing CASCADEDELETE.Hope it is not too much of a burden to add itStefanoInviato da iPhoneIl giorno 30 mag 2024, alle ore 00:03, Luke ***@***.***> ha scritto: I've been thinking about @INSTANCETABLE_REF recently, and I do like the idea of adding an extra option - @INSTANCETABLE_REF_CASCADEDELETE, or something like that. I checked and the redcap_save_record() hook is called when deleting a form, so it would be possible to check whether there are suitably tagged instance tables on the form being deleted. I've added this to my to-do list... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> Informativa sulla Privacy: https://www.unibs.it/it/node/1452

[biostatUniBS]

Hi @lsgs! Any news on this issue?

S