getPendingTransaction Design

[sujitv19196]

SupplyChainTransactions:

• Add a method in this class to get the most recent pending and verified transaction (not premature, not accepted, and not rejected)
• Will consolidate all record keeping to this contract for a clean design
• Have 3 arrays instead of one for the transactions so that we can pull the most pending transaction in a more efficient way than looping through the array --One for accepted --One for rejected --One for total/verified --This way is better for record keeping purposes
• If this is not possible, we can have an integer index that stores the index of the most pending transaction in the array

Manufacturer and Farmer:

• Stay the same because the other classes have to create a pipeline to interact with these contracts
• These “object” contracts don’t have to do anything

Carrier:

• getPendingTransaction will connect the SupplyChainTransactions contract to Carrier
• We can use the getPendingTransactions[-1] from the method in the SupplyChainTransactions contract This makes sense logically and applies to reality because the carrier can be blind to the knowledge of the materials. It just needs to know locations.

[platocrat]

@sujitv19196 @vaishumyadam great job you two!

Sorry for being flat voiced during our meeting. Was trying to think of suggestions that were not coming to me at the time 😅

So, the suggestion I had was to do something about the redundancy of having 3 arrays for txns.

This immediately appears too redundant. What I was thinking, instead of using a mapping after refreshing my memory, is to use an enum for the txn status. It would look something like this:

// Where `Pending` is the default value as the first member
enum TxnStatus { Pending, Accepted, Verified, Premature, Rejected }

struct Transaction {
    string name;
    string description;
    string rejectedMsg;
    uint256 quantity;
    address currentOwner;
    address recipient;
}

Each of the members in the enum TxnStatus are numbered, where Pending = 0, Accepted = 1, etc.

So, changing the state of a txn would be done by changing the state in the enum.

Then, you could wrap enums with transactions like this:

// Where `Pending` is the default value as the first member
enum TxnStatus { Pending, Accepted, Verified, Premature, Rejected }

struct TxnRecord {
    TxnStatus txnStatus,
    mapping (uint => Transaction) transactions
}

struct Transaction {
    string name;
    string description;
    string rejectedMsg;
    uint256 quantity;
    address currentOwner;
    address recipient;
}

Finally, the resulting data could look something like this:

{      
    // all pending transactions
    txnStatus: 0, 
    transactions: {
        0: {...},
        1: {...},
        2: {...},
        ...
    },
},
{
    // all accepted transactions
    txnStatus: 1,
    transactions: {
        0: {...},
        1: {...},
        2: {...},
        ...
    },
},
{
    // all verified transactions
    txnStatus: 2,
    transactions: {
        0: {...},
        1: {...},
        2: {...},
        ...
    },
},
{...}

Let me know if this makes sense and what you two think. Do you both think this is implementable? Or does this complicate what you both have already?

@orangewit3 Eager to hear what you all think, as this suggestion is open for discussion.