Yes, you can update multiple explicit and/or implicit private data collections in a single transaction. Each org-specific implicit private data collection has an endorsement policy of the associated organization. So a client from OrgA could submit an update for OrgA collection and OrgB collection, so long as they get an endorsement from an OrgA peer and OrgB peer. The updates would be applied atomically assuming the transaction is validated. The chaincode can have access control logic that either allows or disallows these cross-org updates, for example the chaincode can check that the client MSPID matches the endorsing peer's MSPID, if you want to restrict such cross-org updates for certain transactions, but allow it for other transactions.

You may be interested in a new sample that we are working on to demonstrate these concepts: https://github.com/hyperledger/fabric-samples/pull/174.
In the sample, private data associated with a transferred asset is deleted from seller's private data collection and added to buyer's private data collection in a single transaction that gets endorsed by both organizations.

In terms of the complexities associated with explicitly defined static private data collections, I was referring to same thing as you - managing an ever-growing number of collections that require approval from other organizations.

While it sounds like either existing approach would work in your scenario, it also sounds like the 'local collection' proposal (if implemented in the future) would simplify things for you, such that the private data hash is stored once in the common chaincode namespace, while the originating client chooses which organizations should receive the actual private data.


Dave Enyeart

omer.glam---05/13/2020 08:28:57 AM---Hi David, thank you for the prompt response. >

From: omer.glam@...
To: fabric@...
Date: 05/13/2020 08:28 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Private data collections recommended usage
Sent by: fabric@...

---

Hi David, thank you for the prompt response.

There is also a 3rd option which is to use an implicit collection per org, and have an organization share the private data with another organization's implicit private data collection on a need-to-know basis. The receiving organization can verify the private against the on-chain hash of the sending organization. This pattern is one of multiple patterns mentioned here:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data

interesting, can we update multiple, cross organizations implicit collections in that same transaction (given all of the collection's organizations are endorsing the transaction ) ?
the goal is to be able to keep the data up to date across all collections where the data is shared, preferably doing so under a single transaction.

I would suggest either pattern 1) or pattern 3). Pattern 2) will be challenging to manage if you have many pairs of organizations. Use pattern 1 for less duplication of data and more fine grained access control. Use pattern 3 if you want clients to query only their own org's peer. Your choice.

can you elaborate on the challenges of many collections may impose?
in our perspective the static nature of collections definitions might make operating large amount of collections complex since it require the other organization approval on the new or updated collection definition, but for our use case we can solve this as part of our process of bootstrapping a new organization to the channel (creating the per organization collection between the new organizations and existing organizations).
are there are any other issues we are overlooking here?

Thank you,
Omer