Skip to content

Conversation

@0xclem
Copy link
Contributor

@0xclem 0xclem commented Sep 3, 2021

No description provided.

@0xclem 0xclem requested a review from dbeal-eth September 3, 2021 00:25
Copy link
Contributor

@dbeal-eth dbeal-eth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very nice 👍 only minor things to confirm


export function handlePositionModified(event: PositionModifiedEvent): void {
let futuresMarketContract = FuturesMarketContract.bind(event.transaction.to as Address);
let proxyAddress = futuresMarketContract.proxy();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems really expensive to run a contract call here in order to set an ID... isn't there a better way to do this, such as using the FuturesMarketEntity asset instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah problem is the event doesn't emit the asset. And the from address is the underlying contract, which means we need to retrieve the proxy address first so we can match the position entity with the market one :(

margin: BigInt!
entryPrice: BigInt!
exitPrice: BigInt
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might want to add entities to track position histories as well (it can simply be a convenient store of events which can be displayed on a "Trading History" page or something)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It kinda is already since we have an ID, which comes from the contract. Every different ID is a new position. So calling this entity by account or timestamp will give us a history

@dbeal-eth
Copy link
Contributor

can this PR be closed? the changes should be pushed to the main branch and be compatible with how the main subgraphs work.

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

Successfully merging this pull request may close these issues.

5 participants