Solidity Development – How to Prevent Complete Loss of State if a Call Fails Using address.call()

Deleting data does free up state space on clients using State Tree Pruning and should be done where possible when ever it is no longer required.

However mappings cannot simply be deleted in a single operation as the contract itself doesn't know where the data resides in the state address. For that it requires the key to be provided in order to delete the individually mapped elements.

Unbounded arrays, such as uint[] bytes etc, can be deleted in the one solidity operation however, the EVM must iteratively delete each slot individually. Care must be taken not to let such arrays grow too big because a future bulk delete operation may exhaust the block gas limit and brick your contract. The lesson here being that your garbage collection should also be designed to be atomic.

Storing new data is at a cost of 20000 per slot while overwriting data costs only 5000. Deleting data also costs 5000 per slot but returns a 15000 gas per slot refund at the end of your call.

What Rob has suggested is good practice with arrays because you can reuse reinitialised storage simply by setting length to 0. However you aren't using arrays but mappings which is a whole other ball game.

So, from your code fragments...

struct data {
    //defined inside a Library.
    mapping(address => Library.Struct[]) my_status;
}

mapping(address => data) clusterContract;
data list;     
clusterContract[id] = list;

...

clusterContract[msg.sender].my_status[id].push( Library.Struct({ status: status_ }));

when you try:

delete clusterContract[msg.sender].my_status; //<=error occurs.

you are trying to delete an entire mapping in one go because .mystatus is defined as:

mapping(address => Library.Struct[]) my_status;

but a mapping itself can't be deleted, only it's elements.

When I work with mappings of structs in particular, I write deconstructors to clean them up. So something like:

function destroy(id) internal

{
   delete clusterContract[msg.sender].my_status[storedIDs[id]]; 
}

But again try to design toward atomic operations with known life cycles rather than having to rely on expensive and messy bulk cleanup.

That's because state variables are packed in storage slots when possible.

Your variables have the following size in storage :

boolean : 1 byte
uint8   : 1 byte 

Given that a storage slot is 32 bytes, all three of them can fit in the first slot (0).

You can check it with this function :

function getSlots() public view returns (uint256, uint256, uint256) {
  uint256 slotVar1;
  uint256 slotVar2;
  uint256 slotVar3;

  assembly {
    slotVar1 := var1.slot
    slotVar2 := var2.slot
    slotVar3 := var3.slot
  }

  return (slotVar1, slotVar2, slotVar3); // 0, 0, 0
}

Now, because they are packed in the same slot they cannot have the same offset :

function getOffsets() public view returns (uint256, uint256, uint256) {
  uint256 offsetVar1;
  uint256 offsetVar2;
  uint256 offsetVar3;

  assembly {
    offsetVar1 := var1.offset
    offsetVar2 := var2.offset
    offsetVar3 := var3.offset
  }

  return (offsetVar1, offsetVar2, offsetVar3); // 0, 1, 2
}

Which is reflected by the value slot 0 itself :

0x0000000000000000000000000000000000000000000000000000000000080001

Where byte 0 : 0x01 is var 1 (bolean true), byte 1 : 0x00 is var 2 (boolean false) and byte 2 : 0x08 is var 3 (uint8 8).

To get the third variable, you want 1 byte from storage slot var3.slot starting at offset var3.offset :

function getThirdVariable() public view returns(uint8) {
  uint8 value;

  assembly {
    let tmp := sload(var3.slot)           // get the value at var3.slot
    tmp := shr(mul(var3.offset, 8), tmp)  // shift that value by var3.offset * 8 bits to the right
    value := tmp                          // store the result for return
  }

  return value; // 8
}