@Johan_Sjodin thanks for followup. I agree the owner of the club can archive, as my ExpensePool example demonstrates the same concept. And yes i agree the club is a minimal example, but in that example it passes the club into the membership and proof, essentially making the club immutable unless you are willing to re-create contracts for membership and proof whenever the club contract has changes.
This is the pattern I am identifying/questioning in my first comment of this thread. Many of the examples are based on designs of immutable parent contracts that if changed would require re-creation of all child contracts. Of course this story works well for the basic concepts, but I keep seeing the failure when trying to scale the workflow of the contracts to real-world structures/business workflows (as shown in comment).
has there been testing or experience on if it is “better” to re-create contracts vs create loose key based linkages between contracts? Example: If the Club is immutable, then a change to the club would require complete archiving of the club and child contracts followed by the recreation of the club with the new data + re-creation of all child contracts using the new version of the club. At ~scale is this a lot of/burdensome changes against the ledger??
vs if the club is mutable similar to my ExpensePool example above, then the linkages between contracts are based on Key and lookups during choices instead of using a static already passed club within the child templates/contracts. A ~caveat problem is that ensure cannot seem to use fetchByKey, so potential limitations there (as per comment in update-in-ensure-clause thread).