Feat/index account #111
Feat/index account #111
Conversation
ErikssonJoakim
force-pushed
the
feat/index-account
branch
from
1ee2caa
to
476afd5
Compare
ErikssonJoakim
force-pushed
the
feat/index-account
branch
from
476afd5
to
a68e270
Compare
ErikssonJoakim
force-pushed
the
feat/index-account
branch
from
a68e270
to
9e3ce9c
Compare
|
@coderabbitai review |
WalkthroughThis update expands the data model of a Cosmos SDK blockchain application, introducing new types and fields. It enhances contract storage and permissions handling, adds functions for unique ID generation, and refines objectarium object handling. Changes
TipsChat with CodeRabbit Bot (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (4)
- schema.graphql (6 hunks)
- src/mappings/contractHandlers.ts (1 hunks)
- src/mappings/helper.ts (1 hunks)
- src/mappings/objectariumHandlers.ts (5 hunks)
Files skipped from review due to trivial changes (1)
- src/mappings/helper.ts
Additional comments: 17
src/mappings/objectariumHandlers.ts (7)
11-18: The new imports
ObjectariumObjectPinandAccountfrom../typesandobjectariumObjectPinIdfrom./helperare introduced. Ensure these are used appropriately in the code.63-78: The code checks if an account exists for the sender. If not, it creates a new account with the sender's public key and an empty balance. This is a good practice to ensure that an account exists for each sender.
80-94: The code creates an
ObjectariumObjectwith the sender's ID and contract. If the object is pinned, it also creates anObjectariumObjectPin. This is a good practice to keep track of pinned objects.119-135: The
handlePinObjectfunction now creates anObjectariumObjectPinif it doesn't exist. This is a good practice to ensure that a pin exists for each object.152-152: The
handleUnpinObjectfunction now removes theObjectariumObjectPininstead of filtering out the sender from the object's pins. This is a more efficient way to handle unpinning.185-185: The
adminfield is now being extracted frommsg.msg.decodedMsg. Ensure that this field is used appropriately in the code.203-204: The
Objectariumentity now has acreatorIdandownerIdinstead of anowner. This provides more information about the entity.src/mappings/contractHandlers.ts (4)
10-14: The
findEventAttributefunction is used to extract thecontractIdfrom themsgobject. Ensure that themsgobject always contains thestore_codeevent and thecode_idattribute. If not, this could lead to undefined behavior.16-20: The
findEventAttributefunction is used to extract thedataHashfrom themsgobject. Ensure that themsgobject always contains thestore_codeevent and thecode_checksumattribute. If not, this could lead to undefined behavior.26-42: The code checks if the sender account exists, and if not, it creates a new account. This is a good practice to ensure that the sender account always exists before proceeding with the contract creation. However, the
publicKeyextraction could be improved. The current implementation assumes that the firstsignerInfowith apublicKeyis the one related to the sender. This might not always be the case, especially if the transaction has multiple signers. You should verify this assumption.44-45: The
permissionis extracted frominstantiatePermissionusing theAccessTypeenum. Ensure thatinstantiatePermission.permissionalways contains a validAccessTypevalue. If not, this could lead to undefined behavior.schema.graphql (6)
69-125: The new
PublicKeyandAccounttypes are well defined and provide a more structured way to represent accounts in the Cosmos SDK. TheAccounttype includes fields for the account's public key, balances, stored and pinned objectarium objects, created and owned objectariums, created contracts, and contract permissions. This is a significant improvement over the previous representation of accounts as simple strings. However, ensure that all parts of the codebase that interact with accounts have been updated to use these new types.207-223: The new
ObjectariumObjectPintype represents the pin of an objectarium object. It includes fields for the objectarium object being pinned and the account pinning the object. This is a more structured way to represent object pins compared to the previous representation as simple strings. However, ensure that all parts of the codebase that interact with object pins have been updated to use this new type.235-245: The
ObjectariumObjecttype has been updated to use the newAccountandObjectariumObjectPintypes. Thesenderfield now refers to anAccountinstead of a string, and thepinsfield now refers to a list ofObjectariumObjectPininstead of a list of strings. This is a significant improvement over the previous representation. However, ensure that all parts of the codebase that interact with objectarium objects have been updated to use these new types.299-305: The
Objectariumtype has been updated to use the newAccounttype. Thecreatorandownerfields now refer to anAccountinstead of a string. This is a significant improvement over the previous representation. However, ensure that all parts of the codebase that interact with objectariums have been updated to use these new types.337-351: The new
ContractPermissionAccounttype represents an account of a contract permission. It includes fields for the contract with the permission and the account concerned by the contract permission. This is a more structured way to represent contract permissions compared to the previous representation as simple strings. However, ensure that all parts of the codebase that interact with contract permissions have been updated to use this new type.368-379: The
Contracttype has been updated to use the newAccountandContractPermissionAccounttypes. Thecreatorfield now refers to anAccountinstead of a string, and a newpermissionAccountsfield has been added to represent a list ofContractPermissionAccount. This is a significant improvement over the previous representation. However, ensure that all parts of the codebase that interact with contracts have been updated to use these new types.
| for (const permissionAddress in instantiatePermission?.addresses) { | ||
| if (!(await Account.get(permissionAddress))) { | ||
| await Account.create({ | ||
| id: permissionAddress, | ||
| balances: [], | ||
| }).save(); | ||
| } | ||
|
|
||
| await ContractPermissionAccount.create({ | ||
| id: contractPermissionAccountId(contractId, sender), | ||
| contractId: permissionAddress, | ||
| accountId: sender, | ||
| }).save(); | ||
| } |
There was a problem hiding this comment.
The code iterates over instantiatePermission?.addresses and for each permissionAddress, it checks if an account exists, and if not, it creates a new account. Then, it creates a ContractPermissionAccount entry. This is a good practice to ensure that all permission addresses have corresponding accounts. However, the contractId and accountId seem to be swapped in the ContractPermissionAccount.create call. The contractId should be contractId and the accountId should be permissionAddress.
- await ContractPermissionAccount.create({
- id: contractPermissionAccountId(contractId, sender),
- contractId: permissionAddress,
- accountId: sender,
- }).save();
+ await ContractPermissionAccount.create({
+ id: contractPermissionAccountId(contractId, permissionAddress),
+ contractId: contractId,
+ accountId: permissionAddress,
+ }).save();Committable suggestion (Beta)
| for (const permissionAddress in instantiatePermission?.addresses) { | |
| if (!(await Account.get(permissionAddress))) { | |
| await Account.create({ | |
| id: permissionAddress, | |
| balances: [], | |
| }).save(); | |
| } | |
| await ContractPermissionAccount.create({ | |
| id: contractPermissionAccountId(contractId, sender), | |
| contractId: permissionAddress, | |
| accountId: sender, | |
| }).save(); | |
| } | |
| await ContractPermissionAccount.create({ | |
| id: contractPermissionAccountId(contractId, permissionAddress), | |
| contractId: contractId, | |
| accountId: permissionAddress, | |
| }).save(); |
| id: sender, | ||
| pubKey: publicKey && { | ||
| typeUrl: publicKey.typeUrl, | ||
| key: Buffer.from(publicKey.value).toString("base64"), |
There was a problem hiding this comment.
Not correct. What you have is a protobuf Any. This Any type has a typeUrl that tells you what kind of data it contains, and a value which is the data itself in a specific format. You can't just convert the data into base64 directly, because you'll only get the binary form of that data.
Instead, you should use the typeUrl to understand what type is, knowing that, decode the binary data into its proper form. After that, you can get a string representation of it.
For instance, for the secp256k1 public key type, you can get the compressed base64 representation like this:
const pk = PubKey.deserializeBinary(new Uint8Array(publicKey.value));
const key = pk.getKey_asB64();which gives:
"pubKey": {
"typeUrl": "/cosmos.crypto.secp256k1.PubKey"
"key": "A8Ny+hVbRIB8h5iiF7d4rSS+9ts06W2t1p5riyOIl1Pm",
},Verification:
➜ okp4d debug pubkey-raw "A8Ny+hVbRIB8h5iiF7d4rSS+9ts06W2t1p5riyOIl1Pm"
Parsed key as secp256k1
Address: 1BC29537C771DCA2C365EE81B39B44042F916DF6
...
➜ okp4d debug addr 1BC29537C771DCA2C365EE81B39B44042F916DF6
Address: [27 194 149 55 199 113 220 162 195 101 238 129 179 155 68 4 47 145 109 246]
Address (hex): 1BC29537C771DCA2C365EE81B39B44042F916DF6
Bech32 Acc: okp41r0pf2d78w8w29sm9a6qm8x6yqshezm0k6vwcrg
Bech32 Val: okp4valoper1r0pf2d78w8w29sm9a6qm8x6yqshezm0k0t73af
|
Switching to draft - code needs to be improved. |
ccamel
force-pushed
the
main
branch
5 times, most recently
from
d6b456c
to
9280ca2
Compare
ccamel
force-pushed
the
main
branch
2 times, most recently
from
c55941b
to
02b1c31
Compare
This PR is a first attempt at indexing accounts in the blockchain. It indexes basic accounts when they interact with the objectarium smart contract or when they store a contract on the blockchain.
Summary by CodeRabbit