Support more data types in GraphQL

[yorek]

https://github.com/Azure/hawaii-gql/blob/33cc4d0633ced93f4d767893ed679674a9369857/DataGateway.Service/Models/DatabaseSchema.cs#L44

I guess the list is very limited just 'cause we're in early dev stage, so I might say something obvious, but we need to add more data types here. All the most common supported data types in each database I guess. We then need to figure out if and how to support database-specific data types.

• [x] #774
• [ ] #444

[JelteF]

Yeah, that's definitely something to address in one of the next milestones.

[yorek]

Moving back to M1, we cannot go public without a complete support for the most basic types

[Aniruddh25]

What are the basic types you have in mind that will be needed for M1 additionally ? I see: 1) Boolean. 2) Decimal i.e. fractional values.

Any more ?

We already support 1) String 2) BigInt

[yorek]

Yeah and also (for Azure SQL):

• Date
• Time
• DateTime2
• Geometry
• Geography
• JSON (we don't have a specific data type but it must be possible to specify if a string value is containing JSON already and thus should not be escaped)

In general is important to create something that is easy extensibile and can correctly handle, now or in future, special data types that are specific for each database.

[aaronpowell]

From the GraphQL end, the supported scalar types is pretty small, Int, Float, Boolean, String and ID (which is commonly a string) - https://spec.graphql.org/October2021/#sec-Scalars. There's also support for List of types which will be needed.

There's also Enum support, which can probably just be treated as a string through serialization.

Biggest gotcha might be custom scalar support which forces the server to handle the serialization/deserialization of the type (here's a Date scalar example, I'll create a discussion elsewhere on custom scalars.

[JelteF]

uuid also an important type to support (for Postgres at least). In addition to the Postgres equivalents of the ones that @yorek mentioned for Azure SQL.

[aaronpowell]

There's the reference list for each of the three SQL backends:

• Azure SQL
• PostgreSQL
• MySQL

I'd argue that not all are going to be needed, especially not initially, but it's worth having an idea of what someone could need to map.

Are Postgres's uuid and Azure SQL's uniqueidentifier comparable? I'm pretty sure they are.

[aaronpowell]

I've created a PR to start fleshing out tests that we can use for data type mapping - https://github.com/Azure/hawaii-gql/pull/237

[JelteF]

Created this separate issue, which is relevant to this: https://github.com/Azure/hawaii-gql/issues/238

[gledis69]

On the technical considerations side of this I created #239. We may want to create a type util/manager class to handle type conversion / validation.

[aaronpowell]

I just noticed today that Hot Chocolate has some additional scalar types it ships with (https://chillicream.com/docs/hotchocolate/defining-a-schema/scalars/#net-scalars) and more in an additional NuGet package (https://chillicream.com/docs/hotchocolate/defining-a-schema/scalars/#additional-scalars)

[michaelstaib]

For

• Geometry
• Geography

There is a spatial package: HotChocolate.Types.Spatial

[seantleonard]

Support for SQL Server/ Azure SQL spatial/geography types is being tracked in #1397. this would apply to both REST and GraphQL