-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Known Issue] Detect JSON columns in Azure SQL #444
Comments
@gledis69 can you please take a look at this issue? |
@yorek what would be the desired output for |
@gledis69 given that in the {
"data": {
"todos": {
"items": [
{
"id": 10000,
"title": "item-001",
"completed": false,
"tags": [
{
"tag": "red"
}
],
"category": {
"id": "f",
"category": "Family"
}
}
}
}
}
} basically: just pass the JSON as is, without encoding it. |
Not need to have support for Filter, Order but for Mutation for JSON type |
From @gledis69 : This turned out to be more involved that I imagined, The core problem is that our DbDataAdapter approach that we use to detect column types just doesn't detect json-s, so we'd have to rewrite column type detection to querying the db and analyzing the response similarly to what we do to detect fk-s. |
Moving to Jan2023 with regards to the new finding |
From @gledis69: json columns need to be handled either by:
2 is probably more feasible. Part of me doesn't like that since it is very particular and not a general scalable solution, but then realistically we already cover most of the commonly used types so it is not very likely we would need to do this for other types in the future hopefully |
I think that 1 is something that will be needed anyway at some point. AFAIK we're using the ADO.NET native support for discovering metadata, but that will not work, fo example, on Synapse. Maybe we can start with 2, but let's plan for 1 |
Not enough time to do this with competing deadlines in Jan203. I agree let's do 1 since we need to support Synapse anyway and its unfortunate that ADO.NET doesn't have that support yet. |
@Aniruddh25 do you know if adding this support is on the roadmap for the ADO.NET team? I can try and find a contact if needed. |
I was reflecting on this while working on some Blazor samples and how we'd best go about representing the JSON type in GraphQL. Presently, we end up with a generated GraphQL type like so: type Todos {
id: Int!
title: String!
description: String!
completed: Boolean!
tags: String!
} Looking at the original structure of type Tag {
tag: String!
} And that'd see us with a field This isn't practical though, as we can't deserialize every JSON field to work out what the "shape" is to then know what GraphQL type to generate should look like, and what happens when you've got optional fields in the JSON, do we have to deserialize a subset of them to work out what the possibilities look it? Proposal - Custom Scalar typesBack to my idea, we could use custom scalar types for these JSON fields, generating a "unique type" for each JSON field, meaning out scalar Todo_Tags
type Todos {
id: Int!
title: String!
description: String!
completed: Boolean!
tags: Todo_Tags!
} Admittedly, this won't really do anything different at a server level, that'll still return a If you're building a .NET client with Strawberry Shake you can define custom serialization for a particular scalar type. urql can also support it and it's possible with Apollo (although not well supported). But also it won't have any real breaking downstream impacts as the change is only masking that it's a Alternatively it could be set as a |
Because curiosity meant that I needed to dig into this more I decided to look at what we need to do to identify JSON columns. PostgreSQL (and I expect MySQL but didn't test) should be reasonably easy to detect as they have a column type of Azure SQL is a little harder as it isn't a data type but it's a constraint on the table that we can query for and then find the column that the constraint is applicable to. Here's a SQL query that we can execute: select schema_name(t.schema_id) + '.' + t.[name] as [table],
col.[name] as column_name,
con.[definition]
from sys.check_constraints as con
left outer join sys.objects as t
on con.parent_object_id = t.object_id
left outer join sys.all_columns as col
on con.parent_column_id = col.column_id
and con.parent_object_id = col.object_id
where lower(con.[definition]) like '%isjson%'
and con.is_disabled = 0 With this we could add another property to |
We should be able to automatically detect if a column contains JSON data and avoid escaping it in the output. Right now if I have the following table:
and I store JSON data in the "tags" column, I get the following output:
where
tags
contains encoded JSON...even if the content is valid JSON itself. Right now Azure SQL DB doesn't have a native JSON data type, but we can check if a column contains JSON data by checking the check constraint that should have been created to allow only JSON data to be inserted (see table definition above). This query can return which columns should be treated as JSON:The text was updated successfully, but these errors were encountered: