Schema Migrations #1275
Replies: 1 comment
-
Hi, B> Assume for a moment a scenario where SubQuery is a parachain
ii) xTokens Pallet with tokens similar to Moonbeam xc20 tokens (i.e. tokens that have both a Substrate representation and ERC20 compatibility) iii) Includes an Open Democracy Pallet very close to the current Substrate Democracy Pallet with the added functionality that each team that is admin of a SubQuery Project, if it wants, it can register its own Token (part of AssetsRegistry/xTokens) and use this in the Democracy Pallet. Play Scenario |
Beta Was this translation helpful? Give feedback.
-
Background
If we have an existing SubQuery Project hosted and we want to amend it in the following scenario
Scenario A is now supported via #1214 - you can reindex from a certain block height
Scenario B and C are not yet supported because it means a schema and db migration must occur.
Proposal
Allow users to provide a versioned list of GraphQl schemas (schema.graphql) files in the project manifest
Use Sequelize to migrate these schemas (https://sequelize.org/docs/v6/other-topics/migrations/)
subql
cli to allow a user to create migrations files, then reference these migrations file in theversions
array above. Additionally this means users can fine tune the migrations filesQuestions
Question 1: Is it possible to amend like in all scenarios an existing SubQuery Project hosted on SubQuery Network using code (no manual steps) and preserving the previous indexing/database, by indexing and adding to the existing database from the last block we updated the code, instead of re-indexing from scratch for all entities?
E.g. Lets assume we want to query about transfers of MOVR for account 0x123 on Moonriver
a) We can query the Moonriver dictionary
b) We can write our own SubQuery Project that indexes only the relevant event
Question 2: What are the advantages and disadvantages between A and B/C?
For example (some of these are obvious to us)
In b) we can add our own code and create our own entities and form the database as we want it
In a) if in the future we want to query staking of MOVR then this is readily available in the dictionary. But for b) we have to amend our existing project to index another event
Is it the case that the fees for a Dictionary query will be more expensive than an Individual SubQuery Project on the SubQuery Network? - Unsure at this stage, Dictionary will likely be subsidised somewhat
Is it the case that the query in our individual SubQuery Project will be significantly faster than the equivalent query on SubQuery Moonriver Dictionary? - Yes
Beta Was this translation helpful? Give feedback.
All reactions