Highlights
Limits
TheGraph has a limit of returning a maximum of 1000 elements per request, with a default of 100 elements. Keep this limit in mind when building your queries. Read how to paginate (opens in a new tab).
Indexing errors
In rare cases indexing errors of new data may occur in subgraph nodes. In that case queries will throw an error with no data by default.
We're reacting fast on such accidents. But while it isn't fixed, you can add param subgraphError: allow to your queries to ignore these errors and work with existing data.
Addresses
When working with TheGraph, all address values are stored in lowercase. This means that when passing variables to
queries, it's important to convert the transmitted value to lowercase, or use the _contains_nocase postfix.
IDs
When working with TheGraph, efficiency matters. The secret sauce lies in their unique id: ID! (TheGraph IDs) for @entity directives in schemas.
These IDs, when used in queries, speed up request execution time.
To maintain clarity and distinction from TheGraph IDs, Azuro assigns specific prefixes to its entity IDs, such as sportId for sports and gameId for games.
To construct a unique TheGraph ID, Azuro merges various entity parameters, ensuring each ID is one of a kind.
Want to use, for example, Game or Condition TheGraph IDs in your code? It's as easy as this:
const gameEntityID = `${liquidityPoolAddress.toLowerCase()}_${gameId}`
const conditionEntityID = `${coreAddress.toLowerCase()}_${conditionId}`Check out the full list of TheGraph ID getters (opens in a new tab)
Remember, when using these getters, ensure that addresses are converted to lowercase.
Entity Duplications
There can be several LP contracts within a single blockchain network. There are several reasons for this, such as
managing different currency pools or addressing risk management concerns.
Each LP contract can contain multiple Core contracts, with each Core contract differing in terms of the logic
used for different casino games or pre-match/live betting. For example, the logic for pre-match/live betting may
differ from that used for other casino games.
The presence of multiple identical contracts in the Azuro Protocol can lead to entities with the same Azuro IDs (e.g. gameId, conditionId). This is
because entities created on different contracts may share the same ID, which can make it difficult to distinguish between them.
For example, different LPs may have the same games with the same gameId, while conditions created on Core contracts
may have the same conditionId.
When interacting with entities in the Azuro Protocol, it's important to use the coreAddress and lpAddress properties
to identify the specific contract to which the entity belongs.
For example, when querying for games, you should include the lpAddress as a filter to ensure that you are only retrieving
games from the correct LP contract. Similarly, when placing bets, you should include the coreAddress to ensure that
the bet is being placed on the correct Core contract.
By using these additional properties to identify the specific contract and entity, you can help prevent issues related to duplicate IDs and ensure that your application is able to function as intended.