I want to implement a database in a private blockchain. It consists of four tables and my idea is to use four smart contracts, one for one table. For each table i'll put the corresponding attributes and its relative CRUD methods in its corrispondent smart contract (i found a nice explanation of CRUD methods here).

Since the CRUD operations behave in a similar way for the four smart contracts, is there a way (or a design pattern) to uncouple the CRUD operations from the definition of the smart contract? So that each smart contract invokes CRUD methods that are defined only one time (and not in each smart contract, in a redundant way) maybe in a separate smart contract.


Thanks for the mention.

The gist of it is wrapped up in this library. https://github.com/rob-Hitchens/UnorderedKeySet

The same instance of the library can be used by all four contracts, while tbe four contracts hold the state and the mapped structs with fields that are not ID.

There is also a LinkedKeySets library that may be of interest if there are referential integrity constraints between the four sets. Experimental. https://github.com/rob-Hitchens/LinkedSets

Hope it helps.

  • Hi, thanks for the reply. In "HitchensUnorderedAddressSet.sol", why in the Count method, the Set argument uses the storage keyword ? The method doesn't persistently modify that argument... – AleWolf May 12 '19 at 14:16
  • The set resides in the contract that calls the library. The library works on it, but it doesn't store it. The storage variable is a way of passing in the whole shebang with a storage pointer. See the contracts say, using ...Lib for ...LibSet, then cast a variable as a Set. That first argument gets passed in with some syntax sugar. It goes MyVarCastAsSet.count (). Where is the argument count expects? It is the whole set as a storage pointet. – Rob Hitchens May 12 '19 at 17:31
  • Since an example of smart contract that i want to create contains the data of a database table and the CRUD methods that manipulate the data, i have to modify your library file because in your code the key of a record is an object of address type while in mine it's simply an int number. Is this correct ? – AleWolf May 12 '19 at 19:25
  • The UnorderedKeySet lib uses a bytes32. That was the original version with re-use in mind because bytes32 can encapsulate any of the fixed sized types. It was a little wordy with address and that's common so I decided to make a variant for that case. You could use the original and just bytes32(myUintVal) in place, or yes, you could easily refactor it use uint natively, i.e. UnorderedUintSet. – Rob Hitchens May 12 '19 at 19:29
  • This, because even though it works, address to bytes32 is bytes32(uint160(uint(myAddressKey))); which I found a little hard on the eyes and a little heavy given that addresses are a common use-case for such sets. – Rob Hitchens May 12 '19 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.