Alex asked me to add an issue for some of the other upload issues he faced so we could track them better.
When we upload a table without a key, an incrementing integer is used for each row. This works and allows a user to upload data but could cause headaches when trying to create networks, since those values need to be known for _from and _to.
To better support this use case, we should allow specifying a _key column (at upload and after), so a user can more easily create connections between nodes.
Additionally, we should allow a user to specify which column to match on when we're uploading an edge table for example:
source,target
1,2
2,3
5,4
And the user could specify that source maps to a-node-table/identity-col and target maps to a-different-node-table/ID.
This means that the restriction on only creating edges by pointing at the _key column is removed. As a technical detail, we'd likely need to figure out some way to convert between the values the user provided and the actual _key value for that row.
Alex asked me to add an issue for some of the other upload issues he faced so we could track them better.
When we upload a table without a key, an incrementing integer is used for each row. This works and allows a user to upload data but could cause headaches when trying to create networks, since those values need to be known for
_fromand_to.To better support this use case, we should allow specifying a _key column (at upload and after), so a user can more easily create connections between nodes.
Additionally, we should allow a user to specify which column to match on when we're uploading an edge table for example:
And the user could specify that source maps to
a-node-table/identity-coland target maps toa-different-node-table/ID.This means that the restriction on only creating edges by pointing at the _key column is removed. As a technical detail, we'd likely need to figure out some way to convert between the values the user provided and the actual _key value for that row.