1

I'm newbie with Solidity and trying to make some smart contract for eCommerce :D basically.

Here is code of that:

pragma solidity ^0.4.16;

contract ecommerce{

    event OnProductAdd(uint, string, uint);
    event UserInfo(User);

    struct User{
        address _address;
        bytes32 name;
        uint balance;
    }

    struct Product{
        uint id;
        string name;
        uint price;
    } 

    address _owner;

    mapping(address => User) public user;

    Product[] public products;

    modifier isAdmin() {
        require(msg.sender == _owner, "you don't have admin access");
        _;
    }

    constructor() public {
        _owner = msg.sender; 
    } 

    function addProduct(uint _id, string _name, uint _price) isAdmin public {

        products.push(Product({
            id: _id,
            name : _name,
            price : _price
        }));

        emit OnProductAdd(_id, _name, _price);
    }

    function getAllProducts() view public{

       //TODO: return all products 
    }

}

Now, what I want is to get all products, but it's a dynamic array..and we cannot return dynamic array directly in Solidity.
So, what alternate way I can use to get all products?

0

At present, I think that this is the best that you can do:

function getProduct(uint index) external view returns (uint, string, uint) {
    Product storage product = products[index];
    return (product.id, product.name, product.price);
}
  • Yeah, but that I saw with many answers, but it will return only one product, index pass by user. – Hina Khuman Jun 24 '18 at 7:33
  • 1
    "Get All" seems like a natural thing to do in a database-centric world. In my opinion, you need to reconsider the flows so it isn't necessary. For example, any client who wishes to see them all can do so by watching your OnProductAdd log. They can check their own off-chain assessment of the situation with the suggested single row getter. If a client has a complete and verifiable copy of the state, what need is there for a Get All function? Bear in mind that one must design everything for consistent gas cost at any scale - O(1), so linear increases are not acceptable. – Rob Hitchens - B9lab Jun 24 '18 at 7:49
  • @HinaKhuman: I agree with the comment above. Most likely you don't need a the entire array - neither in your on-chain (Solidity) code nor in your off-chain code. So you might want to review the way that you are using this contract and check whether or not it is really imperative to return the entire array to anyone outside of this contract. – goodvibration Jun 24 '18 at 8:01
  • @goodvibration: I've little bit confusion for storage and memory, like in the answer you've used Product storage product, instead if I use Product memory product, the result remains the same, so, any difference between both except gas cost(i.e 10 gas change in this case)? – Hina Khuman Jun 24 '18 at 11:33
  • @HinaKhuman: As far as I understand, storage creates a reference on the stack, while memory creates a copy on the stack. The latter is slightly more expensive, and can also lead to insufficient stack-size (compilation error) in some cases. So use memory if you need a local copy which you can change later on without changing the original array, and use storage in any other case (i.e., if you want to change the global array, or if you need to do read-only operations). – goodvibration Jun 24 '18 at 11:59

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.