You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This more cleanly maps to relational concepts (table schema with fields and a primary key) and reduces the number of new concepts we have to introduce about MUD (key schemas vs value schemas). This also maps well to the query API where "subjects" of a query are represented as field tuples.
query({from: {Position: ['player'],},});
I recognize that this is maybe a little more confusing for folks used to our Solidity table libs, where the input args are keys and output is non-key fields:
(int32x, int32y) = Position.get(player);
But I think coming in with fresh eyes, this still makes sense and is a worthwhile trade-off. In Solidity, you don't want to pass around extra data because of gas, so you likely wouldn't return the same key fields you passed in as arguments.
For ECS usages, we'll likely have a plugin or some other wrapper to help you quickly define components as tables and automate setting up keys, etc.
The text was updated successfully, but these errors were encountered:
(related to #1668)
I want to propose moving away from
keySchema
andvalueSchema
and into a singularschema
definition, e.g.This more cleanly maps to relational concepts (table schema with fields and a primary key) and reduces the number of new concepts we have to introduce about MUD (key schemas vs value schemas). This also maps well to the query API where "subjects" of a query are represented as field tuples.
I recognize that this is maybe a little more confusing for folks used to our Solidity table libs, where the input args are keys and output is non-key fields:
But I think coming in with fresh eyes, this still makes sense and is a worthwhile trade-off. In Solidity, you don't want to pass around extra data because of gas, so you likely wouldn't return the same key fields you passed in as arguments.
For ECS usages, we'll likely have a plugin or some other wrapper to help you quickly define components as tables and automate setting up keys, etc.
The text was updated successfully, but these errors were encountered: