Feature | Support SQL Graph column aliases in SqlBulkCopy

[edwardneal]

Description

This fixes an older issue requesting support for using SQL Graph column aliases as destinations when mapping columns in SqlBulkCopy.

SQL Server synthesises four pseudo-columns in SQL Graph: $edge_id, $from_id, $to_id, $node_id. These appear in node and edge tables. It's possible to query these columns, but internally they map to dynamically-named physical columns. Bulk copies only accept physical column names, so this PR introduces the concept of column aliases to bridge that gap when importing data in a similar way to SQL Server (running statements against the destination table manually.)

Column aliases are designed to be additive: if a physical column named $to_id already exists in a SQL Graph table, the physical column will always be used as the destination. For backwards compatibility purposes, if another source field has already been mapped to a column alias' physical column name, other source fields which might be mapped to the column alias aren't re-mapped; SqlBulkCopy will assume that the user has already done the work needed to get the physical column names and won't trample it.

The end result should be as defined in SqlGraphTables.WriteToServer_CopyToAliasedColumnName_Succeeds: mapping from a field in a DataTable/etc. to $to_id or $from_id will "just work".

The only difference between the way that SQL Server handles these column aliases and the way we handle them is in an edge case: a user creates a SQL Graph table with a column which has an identical name to the column alias. In that specific case, a user can access the column alias by querying $to_id and the physical column by querying [$to_id]. On the other hand, SqlBulkCopy will handle this case by always mapping the data to the physical column. This difference is so that people presently mapping fields to $to_id aren't forced to change their code so that it maps to [$to_id]. I don't think this is a common use case though - I'd struggle to imagine a situation where anyone needs to do this.

Issues

Fixes #123.

Testing

All existing tests pass. I've added two more which check the use cases I can think of:

• Can we copy to a column name using its alias?
• If a table has a physical column with the same name as an alias, does the physical column continue to take priority?

[paulmedynski]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).