I have a parent case and I capture the client information in the parent case. Now I will have a bunch of child cases which might need to use that client information which is present in the parent case. Now I have three approaches.
Propagate the client data from parent to child on instantiation.
Directly refer to the parent data from the child.
Use an SOR approach store the client data in a separate table after capturing the client data at the parent. Propagate the SOR key to the children, and use that key to refer/modify that client information.
I feel third option is best, but there are two types of clients one with Class/Dept as key and another one as Class/Dept/Div as the key, now how do I form the key as Div will be blank for the first type of client. In that case I should just use a Serial number as the key, and manually making sure this serial number is unique when we add each client.
I see no issue with approach #2. The process engine makes sure that when the child is opened, the parent is opened too into pyWorkCover. As long as the child merely needs to read the information from the parent, it will always be available there so propagating or using a 3rd instance is unnecessary overhead. If modifications are required, let's discuss further.
Yes I agree with you, the data when its accessed from a child is only for the Read purpose, because these child cases are not even visible to business, we have created child cases just to achieve the true business parallelism. And I think we should ok to modify the data always on the Parent. The child cases dont need to have the modify capability.