I suggest adding this little code chunk under - Tables to explain the synGetTableColumns function
Changing Table Structure
Get the existing Table schema as a list with synGetTableColumns().
existingSchema <- synGetTableColumns("synID")$asList()
, the section Changing Table Structure contains 2 main actions:
Add a new column
Replacing a column
Which action does adding synGetTableColumns help with? And how can it be helpful here?
I imagined a workflow independent of Synapse web, so that in order to change the table structure, one would first need to fetch the structure.
Ah, I think this is where the concept of object oriented programming comes into play. I recently had a conversation about this with other R users in the slack channel.
In this case, users are not interacting with the columns directly, but through the object that contains it.
In the example, this is how we retrieve the object to change it:
“schema” is an object that represents the table in Synapse. To change the table structure, (add/ remove columns), one would use the object’s provided method addColumn() and removeColumn, like in the docs example:
So the “table structure” to fetch here is retrieve by the code above, and not synGetTableColumns. Does this make sense?
From my discussion with , the problem is that user do not always know which column to remove/ modify, and schema only contains column IDs. So synGetTableColumns will help fetching the list of all columns. By looking at this list, user would be able to find the correct columns to remove/ modify.
The schema object does not include column names or column types.