Support for UDT (hierarchyid, geometry and geography)

[tentone]

• Adds support for hierarchyid, geometry and geography SQL type.
• Currently a panic is thrown when the system tries to scan any UDT (user defined type)
• This has been brought up many times (e.g. 167, 79)
• Doesn't make sense to have a official driver that doesn't support all official SQL types.
• There are some forks such as this one to try to solve this issue and the solutions seems to work correctly for every case.
• I have tested the solution for all proposed types and have implemented a library to handle hierarchyid encoding and decoding in Go, that has been developed with the modified driver.

[tentone]

@microsoft-github-policy-service agree

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 88.23529% with 2 lines in your changes missing coverage. Please review.

Project coverage is 74.82%. Comparing base (9b84d9b) to head (f7bf2e8).

Files	Patch %	Lines
types.go	88.23%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #216      +/-   ##
==========================================
+ Coverage   74.79%   74.82%   +0.03%     
==========================================
  Files          32       32              
  Lines        6379     6396      +17     
==========================================
+ Hits         4771     4786      +15     
- Misses       1325     1327       +2     
  Partials      283      283              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[shueybubbles]

I agree the driver shouldn't panic and hierarchyid seems useful in non-CLR uses.
What are the non-CLR use cases for geometry values not converted to string?

[shueybubbles]

should we open an issue to implement app-supplied callbacks to decode unknown types?

[tentone]

That could be a possible way to support other data types, but i think that these are the only ones that were missing from the driver, aside from really new types like the json type

[tentone]

I agree the driver shouldn't panic and hierarchyid seems useful in non-CLR uses. What are the non-CLR use cases for geometry values not converted to string?

Thank you!

Geometry and geography are useful for example for spatial filtering. for example if you define the geometries for houses you can esily get wich house is at a location X, Y (by intersection) or for example get the closest house to a point etc.

Geography and geometry are similar the main diference between them is that geometry is a more generic for any 2D in a generic X, Y referential and geography restricts its usage to earth coordinates taking account the earth curvature the hemispheres etc

[shueybubbles]

I agree the driver shouldn't panic and hierarchyid seems useful in non-CLR uses. What are the non-CLR use cases for geometry values not converted to string?

Thank you!

Geometry and geography are useful for example for spatial filtering. for example if you define the geometries for houses you can esily get wich house is at a location X, Y (by intersection) or for example get the closest house to a point etc.

Geography and geometry are similar the main diference between them is that geometry is a more generic for any 2D in a generic X, Y referential and geography restricts its usage to earth coordinates taking account the earth curvature the hemispheres etc

I meant - how does a Go app consume the binary values? AFAIK those are serialized CLR objects. Maybe I've misunderstood that.

[tentone]

I meant - how does a Go app consume the binary values? AFAIK those are serialized CLR objects. Maybe I've misunderstood that.

Yes i belive so, there are at leat two libs to support serialization of these in go go-mssqlclrgeo and go-geom