Projected NFT indexing #158
Conversation
gostkin
force-pushed
the
egostkin/index-projected-nft
branch
3 times, most recently
from
3dbe3f6
to
e0d8cac
Compare
| NotInlineDatum, | ||
| } | ||
|
|
||
| impl From<ProjectedNftOperation> for i32 { |
There was a problem hiding this comment.
not sure if it's better or not, but you can use #[repr(i32)] on an enum assign the numbers in the definition, and then this would be just as i32
gostkin
force-pushed
the
egostkin/index-projected-nft
branch
from
3aef4b3
to
959e17b
Compare
gostkin
force-pushed
the
egostkin/index-projected-nft
branch
from
9a24188
to
32de9cd
Compare
| pub struct Model { | ||
| #[sea_orm(primary_key, column_type = "BigInteger")] | ||
| pub id: i64, | ||
| pub owner_address: Vec<u8>, |
There was a problem hiding this comment.
Should this be a Vec<u8> instead of a foreign key into the stake credential table (careful: there is no guarantee this staking key exists in the table)
There was a problem hiding this comment.
Should this be a
Vec<u8>instead of a foreign key into the stake credential table (careful: there is no guarantee this staking key exists in the table)
as soon as there's no guarantee and this address is what we actually get from the plutus datum i think it makes sense to leave it like this
| pub previous_utxo_tx_hash: Vec<u8>, | ||
| #[sea_orm(column_type = "BigInteger", nullable)] | ||
| pub previous_utxo_tx_output_index: Option<i64>, |
There was a problem hiding this comment.
Can these not be a foreign key to the output table?
| pub hololocker_utxo_id: Option<i64>, | ||
| #[sea_orm(column_type = "BigInteger")] | ||
| pub tx_id: i64, | ||
| pub asset: String, |
There was a problem hiding this comment.
Same, we can use a foreign key for this asset as well
| pub tx_id: i64, | ||
| pub asset: String, | ||
| #[sea_orm(column_type = "BigInteger")] | ||
| pub amount: i64, |
There was a problem hiding this comment.
Maybe it's too ugly, but you can probably get the amount information implicitly from the fact you're already referencing the UTXO table
| return ProjectedNftData { | ||
| previous_utxo_tx_hash: vec![], | ||
| previous_utxo_tx_output_index: None, | ||
| address: vec![], | ||
| plutus_data: datum, | ||
| operation: ProjectedNftOperation::ParseError, | ||
| for_how_long: None, | ||
| } |
There was a problem hiding this comment.
Is it really okay to return this in the error state? When does the error state actually happen (when people create a Projected NFT datum that actually contains garbage and wasn't generated with our library?)
| return ProjectedNftData { | ||
| previous_utxo_tx_hash: vec![], | ||
| previous_utxo_tx_output_index: None, | ||
| address: vec![], | ||
| plutus_data: hash.to_vec(), | ||
| operation: ProjectedNftOperation::NotInlineDatum, | ||
| for_how_long: None, | ||
| }; |
There was a problem hiding this comment.
What is the end result of returning this default object if they didn't provide the actual inline datum? We disable this in the smart contract, so we should at least have a comment saying this case is possible to see, but that these aren't spendable (not sure if this actually affects anything from the Carp side though)
There was a problem hiding this comment.
if the object is not an inline datum the contract doesn't accept it and funds are locked forever
| @@ -13,6 +13,7 @@ export interface ISqlBlockLatestResult { | |||
| hash: Buffer; | |||
| height: number; | |||
| id: number; | |||
| payload: Buffer | null; | |||
There was a problem hiding this comment.
Why did this change?
There was a problem hiding this comment.
this query wasn't regenerated before
| }; | ||
|
|
||
| export type ProjectedNftRangeResponse = { | ||
| actionSlot: number, |
There was a problem hiding this comment.
What is "actionSlot"
Keep in mind that when defining the data type, OpenAPI actually looks at the comments you put on these types (which is why we use alias like Address instead of string in the other models)
There was a problem hiding this comment.
action slot -- slot of a block at which the transaction happened
| let datum = match datum_option { | ||
| DatumOption::Hash(hash) => { | ||
| return ProjectedNftData { | ||
| previous_utxo_tx_hash: vec![], |
There was a problem hiding this comment.
We can probably use ..Default::default() to shrink the code for a lot of these
No description provided.