template Member
with
person: Party
organizationOwner: Party
rolesCid: [ContractId Role]
where
signatory person
observer organizationOwner
key (person, organizationOwner) : (Party, Party)
maintainer key._1
choice AddRole : ContractId Member
with
roleCid: ContractId Role
controller organizationOwner
do
create this with
rolesCid = rolesCid ++ [roleCid]
I have this contract, where I use an array of Roles Contract Ids for each member. If i try to update or remove a role, it does not get updated in the corresponding array.
Welcome to Daml Forum.
I may suggest using a contract key for a Role contract and storing these contract keys in the Member contracts instead of ContractIds for the Role contracts. Contract keys provide a stable identifier for something that a contract represents (a possible person’s role in your model). Using a contract key for the Role contract will solve the problem that, whenever you update a Role contract, the ContractId changes and the previous ContractId stored in Member contracts becomes a broken reference. However, if you remove a role, you’d still end up with a case, where a Member contract may reference a Role contract key for which there’s no corresponding Role contract on the ledger. Perhaps this could be acceptable in your model, as you could code around the possibility that not all roles listed in a Member contract may actually exist on the ledger, and you could have some logic to update a Member contract by removing a Role key that doesn’t exist whenever you encounter such Member contract. You could even introduce off-ledger automation that periodically scans the ledger for all Member contracts that have in their payload Role contract keys that don’t have corresponding Role contracts on the ledger, although the benefit of this may not be worth the cost of additional ledger events such automation will create.
This said, it’s not a good idea to think about the ledger as a relational database when you design a solution. It may work on a small scale, but as you scale up to production you will more than likely run into all kinds of performance problems. If you need the properties of a relational database in your project, then use a database for this part, and use the ledger to do what it does well - provide immutable transaction record store distributed across trust boundaries with strictly enforced authorization rules and privacy.