specs: rewrite definition of Read Interface #95
Conversation
| "attestation": 0x0122340 | ||
| } | ||
| ``` | ||
| The precise set of values that needs to be supported still needs to be finalized, but the type system will need to at least allow for strings, ints, bigints, bigdecimals, and byte strings as primitive types. |
There was a problem hiding this comment.
Let's make sure finalizing these types is tracked somewhere. Maybe link to that issue here.
There was a problem hiding this comment.
Tracked here: graphprotocol/graph-node#1096
|
|
||
| The concrete types (i.e., `K` and `V` shown below), as well as the implicit comparator function to determine sort order, are specified by each concrete index type. | ||
| Queries are transmitted as abstract syntax trees, not as text. The precise representation of the abstract syntax tree in JSON still needs to be defined. |
There was a problem hiding this comment.
Same comment as above. Let's link to an issue if we are going to list this as a TODO in the spec.
There was a problem hiding this comment.
Tracked here: graphprotocol/graph-node#1097
| would correspond to this SQL query | ||
| ```sql | ||
| select m.id, | ||
| map(main_band) as mainBand, |
There was a problem hiding this comment.
It seems like the main role that map and collect are playing here are to explicitly normalize the response data.
Is this strictly necessary or could we just infer that we always want to convert a denormalized set of tabular data into a normalized nested object?
Do you see map and collect playing an important role in facilitating other GraphQL queries?
There was a problem hiding this comment.
The main purpose for map and collect is to change the representation of data, and to let us break out of the strict tabular representation that SQL implies by introducing composite values. Without these, we would be restricted to dealing with tables whose columns can only represent scalar types.
I don't think we can infer that automatically; in the example you quote, the use of map and collect directly reflects how relationships are modelled in GraphQL; in our subset of SQL, those relationships aren't expressed directly, and map and collect are used to go from a model that is more flexible in terms of data relationships to the more restrictive GraphQL model.
There was a problem hiding this comment.
Okay that rationale makes sense to me. I'm still a little fuzzy, however, on the syntax you're showing here.
You're calling map and collect in your select statement using the aliases that you assigned to the tables you produced during the join.
It seems like the map and collect should happen "before" the join, while you are producing the tables to be used in the join. By the time you are in the select statement shouldnt "songs" and "main_band" just refer to column names? What would it mean to operate on a table in this context?
Maybe something like:
select m.id,
mainBand.value,
songs.values
from musicians m
left outer join ( map (select id from bands) over id) as main_band
on (m.main_band = main_band.key)
left outer join (collect (select id, written_by from songs) over written_by) as songs
on (songs.key = m.id)
In the example above I assumed that map produces a table with a key and value column where the value column has the result that you described. I assumed that collect produces a table with key and values columns. In both cases key is whatever column was passed in to the over statement. These might not be the friendliest semantics, but gets the ideas across.
Working through the example I understand better what collect is accomplishing, though I'm still having a little trouble with map. It seems like it's just formatting that could be done by the query engine? I might need a more complete example to drive it home for me.
There was a problem hiding this comment.
That's sorta what would happen behind the scenes, but not how you write this stuff in SQL; you can think of the evaluation of a simple select ... from ... where ... of first taking the tables in the from clause and creating one big result table based on the where clause (and join conditions in the from) The select then talks about which of the columns of that result table to use resp. how to transform columns (in the case of map) into new columns.
I think you are right that we could make do without the map; I'd need to think more about that and sketch out more examples.
|
|
||
| ###### Database Model | ||
| `entitydb` | ||
| ## Cost model |
There was a problem hiding this comment.
Let's link to a tracking issue here as well, which maybe outlines some of the options mentioned here.
There was a problem hiding this comment.
Tracked here: graphprotocol/graph-node#1098
|
A few minor questions/comments but this is looking good! I'm a little hesitant to merge a PR that replaces a complete & self-consistent design w/ so many open TODO's, but as long as we get them tracked as issues and linked it's OK. |
|
I've added links to the tracking issues to the text. I agree that it's unfortunate that we have these open to dos in there, but I also think it accurately reflects what we know right now, and that we should be able to fill these fairly easily once the implementation progresses. |
No description provided.