-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Olympia membership input schema #2303
Comments
Does this mean that for now we should just add the
I don't think we have any extrinsics / events related to that state, should it just be a property that's always
I was thinking about switching to that once it's supported by the runtime (after
I can see the utility of having this state accessible through query node, though I was wondering about the query node efficiency in case we decide to store all the events and extrinsics that get processed and then use aggregate queries (which will obviously have a much higher execution cost than a querying, for example, a single Looking at the wireframes I also didn't see where all of this event data would be needed (perhaps I overlooked something?)
It seems reasonable, I'm not sure what other options are there when it comes to GraphQL schemas and Hydra/warthog support. I was also considering separating generic event data from specific events data (perhaps it may have some value in terms of relationships where event type is not enforced), for example:
The best solution would probably be some kind of inheritance, but it's not obvious to me how this could be supported both on GraphQL schema and database/ORM side (I'm pretty sure it would be tough to implement) |
No, it would mean that we do not use a relationship at all. So the
Correct, this will probably be introduced as an event that is triggered exclusively by the build code for the gensis block. Alternatively it will just be implied genesis value, like the total issuance, which is comitted to in the constitution.
I suggest we add it to the schema now, but do not write any mappings to manage it at all, that way it will be there for the Pioneer devs to see as early as possible, and it is not forgotten.
The simplest example are the event logs showed on a the right hand side of different screens, such as https://www.figma.com/file/pgNl83wgAub186krVkdiuo/Proposals?node-id=183%3A757
Good question, for filtering it would appear to be required actually, so I think it is a must. |
Background
The purpose of this issue is to serve as a discussion thread for the state of the current
Olympia
input schemas.Here is a fully rendition of the current schema, lifted from
https://github.com/Lezek123/substrate-runtime-joystream/blob/olympia-integration-tests/query-node/schema.graphql
Comments
NB: In all comments below I use relationships to
Extrinsic
andBlock
, but we currently cannot filter, order and aggregate through relationships fully, so there is some risk in doing this now. In general it also requires more efforts to get the mappings right. It may be wise to just inline hashes and block numbers for now.If we do want to use them, this is what I currently have
Founding Member Field
Founding member state missing
Avatar Representation
While currently not in the runtime, I think its safe to say that we will use same storage representation as in
Sumer
for avatars, as the storage system will be able to host them. So I suggest we switch to that, check theSumer
branch, which currently has thisRicher representation of origin of membership
There is a way to represent how a membership has been established in a more compact & safe way, using a type like
This would replace
registeredAtBlock
,registeredAtTime
andentry
, however, this representation will make some queries harder, and requires more effort, so it may be useful to just stick to what you currently have. I just wanted to raise your awareness of this type of approach, as I think it will be a consistent question in the future for other schemas.Metadata
Perhaps we should aggregate all the metadata fields together, so its more clear where they are coming from, and perhaps also include some comment about what version of the metadata for memberships this schema is using?
Events
We need to also index all of the events associated with each subsystem, this is needed not only to how a chronological list of events associated with a given member, worker or working group, as is needed in a few places in Pioneer, but it also allows us to compute various historical numbers by using aggregate functions (Joystream/hydra#195), without needing to have explicit query state for this. This could be things like, the total amount of money worker has earned or staked for example.
My approach has been to have an
Event
interface type, and then have that be implemented by anentity
variation for each event in question, like this.Event
Membership events
MembershipSystem
This entity, which has the following comment in my file
"State of the membership system. NB: There should only be one instance of this entity."
is a bit degenerate. It feels awkward to only have a single instance of this entity.
I think an alternative way to do this is to switch the meaning to something like
MembershipSystemSnapshot
, and add a block height field. Then a new entity is created for every block where at least one variable is changed, and initial entity is derived from genesis configuration. If there is more than one update in a block, then that just results in mutating the same entity. So for example, if you in the same block have a proposal to udpate the referral cut, and a separate one to update the membership price, then you still just ahve one snapshot. Now, if someone wants to get the latest state, they just order by block height and set limit to 1. Alternatively, they could access historical values for the system over time, which could be useful for various historical UI views.What do you think?
The text was updated successfully, but these errors were encountered: