Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revising patrons structure #11

Open
madvas opened this issue Jan 25, 2023 · 0 comments
Open

Revising patrons structure #11

madvas opened this issue Jan 25, 2023 · 0 comments
Assignees

Comments

@madvas
Copy link

madvas commented Jan 25, 2023

Seems like none of these parameters are really necessary, since the addPatron function is called only by admin and patron profile data are stored at the different time without a transaction. So when patron has been added, server only needs to know the address.

bytes32 data,
string link,
string ipfsHash,
uint256 index

Same goes here, only address as an argument would be sufficient

bytes32 data,
string memory link,
string memory ipfsHash

So I think we could just have isPatron[*address*] structure instead of the mapping below. I think it's not really necessary for this contract to maintain patrons count, since server-side will be able to easily construct it just from PatronAdded events.

mapping(uint256 => address) public patrons;

And here instead of passing patron_indexes we would pass patronAddresses. (Also please use camelCase everywhere)

function donate(uint256[] memory patron_indexes, uint256[] memory amounts) public payable {

And here instead of passing patron_index we would be passing patronAddress

emit Donate(tx.origin, _msgSender(), amount, patron_index, id);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants