Implement new JSON data type. by Avogar · Pull Request #66444 · ClickHouse/ClickHouse

Avogar · 2024-07-12T15:01:32Z

Changelog category (leave one):

New Feature

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Implement new JSON data type.

Ref: #54864
Closes: #54864
Closes: #53908

Documentation entry for user-facing changes

JSON type

To declare a column of JSON type, use the following syntax:

<column_name> JSON(max_dynamic_paths=N, max_dynamic_types=M, some.path TypeName, SKIP path.to.skip, SKIP REGEXP 'paths_regexp')

Where:

max_dynamic_paths is an optional parameter indicating how many paths can be stored separately as subcolumns across single block of data that is stored separately (for example across single data part for MergeTree table). If this limit is exceeded, all other paths will be stored together in a single structure. Default value of max_dynamic_paths is 1000.
max_dynamic_types is an optional parameter between 1 and 255 indicating how many different data types can be stored inside a single path column with type Dynamic across single block of data that is stored separately (for example across single data part for MergeTree table). If this limit is exceeded, all new types will be converted to type String. Default value of max_dynamic_types is 32.
some.path TypeName is an optional type hint for particular path in the JSON. Such paths will be always stored as subcolumns with specified type.
SKIP path.to.skip is an optional hint for particular path that should be skipped during JSON parsing. Such paths will never be stored in the JSON column. If specified path is a nested JSON object, the whole nested object will be skipped.
SKIP REGEXP 'path_regexp' is an optional hint with a regular expression that is used to skip paths during JSON parsing. All paths that match this regular expression will never be stored in the JSON column.

Creating JSON

Using JSON type in table column definition:

CREATE TABLE test (json JSON(a.b UInt32, SKIP a.e)) ENGINE = Memory;
INSERT INTO test VALUES ('{"a" : {"b" : 42}, "c" : [1, 2, 3]}'), ('{"f" : "Hello, World!"}'), ('{"a" : {"b" : 43, "e" : 10}, "c" : [4, 5, 6]}');
SELECT json FROM test;

┌─json──────────────────────────────┐
│ {"a":{"b":42},"c":[1,2,3]}        │
│ {"a":{"b":0},"f":"Hello, World!"} │
│ {"a":{"b":43},"c":[4,5,6]}        │
└───────────────────────────────────┘

Using CAST from 'String':

SELECT '{"a" : {"b" : 42},"c" : [1, 2, 3], "d" : "Hello, World!"}'::JSON as json;

┌─json───────────────────────────────────────────┐
│ {"a":{"b":42},"c":[1,2,3],"d":"Hello, World!"} │
└────────────────────────────────────────────────┘

CAST from named Tuple, Map and Object('json') to JSON type will be supported later.

Reading JSON paths as subcolumns

JSON type supports reading every path as a separate subcolumn. If type of the requested path was not specified in the JSON type declaration, the subcolumn of the path will always have type Dynamic.

For example:

CREATE TABLE test (json JSON(a.b UInt32, SKIP a.e)) ENGINE = Memory;
INSERT INTO test VALUES ('{"a" : {"b" : 42, "g" : 42.42}, "c" : [1, 2, 3], "d" : "2020-01-01"}'), ('{"f" : "Hello, World!", "d" : "2020-01-02"}'), ('{"a" : {"b" : 43, "e" : 10, "g" : 43.43}, "c" : [4, 5, 6]}');
SELECT json FROM test;

┌─json──────────────────────────────────────────────────┐
│ {"a":{"b":42,"g":42.42},"c":[1,2,3],"d":"2020-01-01"} │
│ {"a":{"b":0},"d":"2020-01-02","f":"Hello, World!"}    │
│ {"a":{"b":43,"g":43.43},"c":[4,5,6]}                  │
└───────────────────────────────────────────────────────┘

SELECT json.a.b, json.a.g, json.c, json.d FROM test;

┌─json.a.b─┬─json.a.g─┬─json.c──┬─json.d─────┐
│       42 │ 42.42    │ [1,2,3] │ 2020-01-01 │
│        0 │ ᴺᵁᴸᴸ     │ ᴺᵁᴸᴸ    │ 2020-01-02 │
│       43 │ 43.43    │ [4,5,6] │ ᴺᵁᴸᴸ       │
└──────────┴──────────┴─────────┴────────────┘

If the requested path wasn't found in the data, it will be filled with NULL values:

SELECT json.non.existing.path FROM test;

┌─json.non.existing.path─┐
│ ᴺᵁᴸᴸ                   │
│ ᴺᵁᴸᴸ                   │
│ ᴺᵁᴸᴸ                   │
└────────────────────────┘

Let's check the data types of returned subcolumns:

SELECT toTypeName(json.a.b), toTypeName(json.a.g), toTypeName(json.c), toTypeName(json.d) FROM test;

┌─toTypeName(json.a.b)─┬─toTypeName(json.a.g)─┬─toTypeName(json.c)─┬─toTypeName(json.d)─┐
│ UInt32               │ Dynamic              │ Dynamic            │ Dynamic            │
│ UInt32               │ Dynamic              │ Dynamic            │ Dynamic            │
│ UInt32               │ Dynamic              │ Dynamic            │ Dynamic            │
└──────────────────────┴──────────────────────┴────────────────────┴────────────────────┘

As we can see, for a.b the type is UInt32 as we specified in the JSON type declaration, and for all other subcolumns the type is Dynamic.

It is also possible to read subcolumns of a Dynamic type using special syntax json.some.path.:TypeName:

select json.a.g.:Float64, dynamicType(json.a.g), json.d.:Date, dynamicType(json.d) FROM test;

┌─json.a.g.:`Float64`─┬─dynamicType(json.a.g)─┬─json.d.:`Date`─┬─dynamicType(json.d)─┐
│               42.42 │ Float64               │     2020-01-01 │ Date                │
│                ᴺᵁᴸᴸ │ None                  │     2020-01-02 │ Date                │
│               43.43 │ Float64               │           ᴺᵁᴸᴸ │ None                │
└─────────────────────┴───────────────────────┴────────────────┴─────────────────────┘

Reading JSON sub-objects as subcolumns

JSON type supports reading nested objects as subcolumns with type JSON using special syntax json.^some.path:

CREATE TABLE test (json JSON) ENGINE = Memory;
INSERT INTO test VALUES ('{"a" : {"b" : {"c" : 42, "g" : 42.42}}, "c" : [1, 2, 3], "d" : {"e" : {"f" : {"g" : "Hello, World", "h" : [1, 2, 3]}}}}'), ('{"f" : "Hello, World!", "d" : {"e" : {"f" : {"h" : [4, 5, 6]}}}}'), ('{"a" : {"b" : {"c" : 43, "e" : 10, "g" : 43.43}}, "c" : [4, 5, 6]}');
SELECT json FROM test;

┌─json────────────────────────────────────────────────────────────────────────────────────────┐
│ {"a":{"b":{"c":42,"g":42.42}},"c":[1,2,3],"d":{"e":{"f":{"g":"Hello, World","h":[1,2,3]}}}} │
│ {"d":{"e":{"f":{"h":[4,5,6]}}},"f":"Hello, World!"}                                         │
│ {"a":{"b":{"c":43,"e":10,"g":43.43}},"c":[4,5,6]}                                           │
└─────────────────────────────────────────────────────────────────────────────────────────────┘

SELECT json.^a.b, json.^d.e.f FROM test;

┌─json.^`a`.b───────────────┬─json.^`d`.e.f────────────────────┐
│ {"c":42,"g":42.42}        │ {"g":"Hello, World","h":[1,2,3]} │
│ {}                        │ {"h":[4,5,6]}                    │
│ {"c":43,"e":10,"g":43.43} │ {}                               │
└───────────────────────────┴──────────────────────────────────┘

Handling arrays of JSON objects

JSON paths that contains an array of objects are parsed as type Array(JSON) and inserted into Dynamic column for this path. To read an array of objects you can extract it from Dynamic column as a subcolumn:

CREATE TABLE test (json JSON) ENGINE = Memory;
INSERT INTO test VALUES
('{"a" : {"b" : [{"c" : 42, "d" : "Hello", "f" : [[{"g" : 42.42}]], "k" : {"j" : 1000}}, {"c" : 43}, {"e" : [1, 2, 3], "d" : "My", "f" : [[{"g" : 43.43, "h" : "2020-01-01"}]],  "k" : {"j" : 2000}}]}}'),
('{"a" : {"b" : [1, 2, 3]}}'),
('{"a" : {"b" : [{"c" : 44, "f" : [[{"h" : "2020-01-02"}]]}, {"e" : [4, 5, 6], "d" : "World", "f" : [[{"g" : 44.44}]],  "k" : {"j" : 3000}}]}}');
SELECT json FROM test;

┌─json────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ {"a":{"b":[{"c":"42","d":"Hello","f":[[{"g":42.42}]],"k":{"j":"1000"}},{"c":"43"},{"d":"My","e":["1","2","3"],"f":[[{"g":43.43,"h":"2020-01-01"}]],"k":{"j":"2000"}}]}} │
│ {"a":{"b":["1","2","3"]}}                                                                                                                                               │
│ {"a":{"b":[{"c":"44","f":[[{"h":"2020-01-02"}]]},{"d":"World","e":["4","5","6"],"f":[[{"g":44.44}]],"k":{"j":"3000"}}]}}                                                │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

SELECT json.a.b, dynamicType(json.a.b) FROM test;

┌─json.a.b──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬─dynamicType(json.a.b)────────────────────────────────────┐
│ ['{"c":"42","d":"Hello","f":[[{"g":42.42}]],"k":{"j":"1000"}}','{"c":"43"}','{"d":"My","e":["1","2","3"],"f":[[{"g":43.43,"h":"2020-01-01"}]],"k":{"j":"2000"}}'] │ Array(JSON(max_dynamic_types=16, max_dynamic_paths=256)) │
│ [1,2,3]                                                                                                                                                           │ Array(Nullable(Int64))                                   │
│ ['{"c":"44","f":[[{"h":"2020-01-02"}]]}','{"d":"World","e":["4","5","6"],"f":[[{"g":44.44}]],"k":{"j":"3000"}}']                                                  │ Array(JSON(max_dynamic_types=16, max_dynamic_paths=256)) │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────┘

As you can notice, the max_dynamic_types/max_dynamic_paths parameters of the nested JSON type were reduced compared to the default values. It's needed to avoid number of subcolumns to grow uncontrolled on nested arrays of JSON objects.

Let's try to read subcolumns from this nested JSON column:

SELECT json.a.b.:`Array(JSON)`.c, json.a.b.:`Array(JSON)`.f, json.a.b.:`Array(JSON)`.d FROM test;

┌─json.a.b.:`Array(JSON)`.c─┬─json.a.b.:`Array(JSON)`.f───────────────────────────────────┬─json.a.b.:`Array(JSON)`.d─┐
│ [42,43,NULL]              │ [[['{"g":42.42}']],NULL,[['{"g":43.43,"h":"2020-01-01"}']]] │ ['Hello',NULL,'My']       │
│ []                        │ []                                                          │ []                        │
│ [44,NULL]                 │ [[['{"h":"2020-01-02"}']],[['{"g":44.44}']]]                │ [NULL,'World']            │
└───────────────────────────┴─────────────────────────────────────────────────────────────┴───────────────────────────┘

We can avoid writing Array(JSON) subcolumn name using special syntax:

SELECT json.a.b[].c, json.a.b[].f, json.a.b[].d FROM test;

┌─json.a.b.:`Array(JSON)`.c─┬─json.a.b.:`Array(JSON)`.f───────────────────────────────────┬─json.a.b.:`Array(JSON)`.d─┐
│ [42,43,NULL]              │ [[['{"g":42.42}']],NULL,[['{"g":43.43,"h":"2020-01-01"}']]] │ ['Hello',NULL,'My']       │
│ []                        │ []                                                          │ []                        │
│ [44,NULL]                 │ [[['{"h":"2020-01-02"}']],[['{"g":44.44}']]]                │ [NULL,'World']            │
└───────────────────────────┴─────────────────────────────────────────────────────────────┴───────────────────────────┘

The number of [] after path indicates the array level. json.path[][] will be transformed to json.path.:Array(Array(JSON))

Let's check the paths and types inside our Array(JSON):

SELECT DISTINCT arrayJoin(JSONAllPathsWithTypes(arrayJoin(json.a.b[]))) FROM test;

┌─arrayJoin(JSONAllPathsWithTypes(arrayJoin(json.a.b.:`Array(JSON)`)))──┐
│ ('c','Int64')                                                         │
│ ('d','String')                                                        │
│ ('f','Array(Array(JSON(max_dynamic_types=8, max_dynamic_paths=64)))') │
│ ('k.j','Int64')                                                       │
│ ('e','Array(Nullable(Int64))')                                        │
└───────────────────────────────────────────────────────────────────────┘

Let's read subcolumns from Array(JSON) column:

SELECT json.a.b[].c.:Int64, json.a.b[].f[][].g.:Float64, json.a.b[].f[][].h.:Date FROM test;

┌─json.a.b.:`Array(JSON)`.c.:`Int64`─┬─json.a.b.:`Array(JSON)`.f.:`Array(Array(JSON))`.g.:`Float64`─┬─json.a.b.:`Array(JSON)`.f.:`Array(Array(JSON))`.h.:`Date`─┐
│ [42,43,NULL]                       │ [[[42.42]],[],[[43.43]]]                                     │ [[[NULL]],[],[['2020-01-01']]]                            │
│ []                                 │ []                                                           │ []                                                        │
│ [44,NULL]                          │ [[[NULL]],[[44.44]]]                                         │ [[['2020-01-02']],[[NULL]]]                               │
└────────────────────────────────────┴──────────────────────────────────────────────────────────────┴───────────────────────────────────────────────────────────┘

We can also read sub-object subcolumns from nested JSON column:

SELECT json.a.b[].^k FROM test

┌─json.a.b.:`Array(JSON)`.^`k`─────────┐
│ ['{"j":"1000"}','{}','{"j":"2000"}'] │
│ []                                   │
│ ['{}','{"j":"3000"}']                │
└──────────────────────────────────────┘

Documentation is written (mandatory for new features)

Information about CI checks: https://clickhouse.com/docs/en/development/continuous-integration/

CI Settings (Only check the boxes if you know what you are doing):

Allow: All Required Checks
Allow: Stateless tests
Allow: Stateful tests
Allow: Integration Tests
Allow: Performance tests
Allow: All Builds
Allow: batch 1, 2 for multi-batch jobs
Allow: batch 3, 4, 5, 6 for multi-batch jobs

Exclude: Style check
Exclude: Fast test
Exclude: All with ASAN
Exclude: All with TSAN, MSAN, UBSAN, Coverage
Exclude: All with aarch64, release, debug

…into json-data-type

…ata-type

Avogar · 2024-07-12T15:01:49Z

I am working on the tests, will add them later

Avogar · 2024-07-12T15:04:16Z

src/Columns/ColumnObject.h

Old implementation was moved to ColumnObjectDeprecated.h/cpp files. Github doesn't show that old code was moved and thinks that the code was just changed. Ignore it and read code in these files as completely new. The same for similar files DataTypeObject/SerializationObject.

robot-clickhouse-ci-2 · 2024-07-12T15:09:57Z

This is an automated comment for commit db691e4 with description of existing statuses. It's updated for the latest CI running

❌ Click here to open a full report in a separate page

Check name	Description	Status
Performance Comparison	Measure changes in query performance. The performance test report is described in detail here. In square brackets are the optional part/total tests	❌ failure

Successful checks

Check name	Description	Status
AST fuzzer	Runs randomly generated queries to catch program errors. The build type is optionally given in parenthesis. If it fails, ask a maintainer for help	✅ success
Builds	There's no description for the check yet, please add it to tests/ci/ci_config.py:CHECK_DESCRIPTIONS	✅ success
ClickBench	Runs [ClickBench](https://github.com/ClickHouse/ClickBench/) with instant-attach table	✅ success
Compatibility check	Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help	✅ success
Docker keeper image	The check to build and optionally push the mentioned image to docker hub	✅ success
Docker server image	The check to build and optionally push the mentioned image to docker hub	✅ success
Docs check	Builds and tests the documentation	✅ success
Fast test	Normally this is the first check that is ran for a PR. It builds ClickHouse and runs most of stateless functional tests, omitting some. If it fails, further checks are not started until it is fixed. Look at the report to see which tests fail, then reproduce the failure locally as described here	✅ success
Flaky tests	Checks if new added or modified tests are flaky by running them repeatedly, in parallel, with more randomization. Functional tests are run 100 times with address sanitizer, and additional randomization of thread scheduling. Integration tests are run up to 10 times. If at least once a new test has failed, or was too long, this check will be red. We don't allow flaky tests, read the doc	✅ success
Install packages	Checks that the built packages are installable in a clear environment	✅ success
Integration tests	The integration tests report. In parenthesis the package type is given, and in square brackets are the optional part/total tests	✅ success
Stateful tests	Runs stateful functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success
Stateless tests	Runs stateless functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	✅ success
Stress test	Runs stateless functional tests concurrently from several clients to detect concurrency-related errors	✅ success
Style check	Runs a set of checks to keep the code style clean. If some of tests failed, see the related log from the report	✅ success
Unit tests	Runs the unit tests for different release types	✅ success
Upgrade check	Runs stress tests on server version from last release and then tries to upgrade it to the version from the PR. It checks if the new server can successfully startup without any errors, crashes or sanitizer asserts	✅ success

UnamedRus · 2024-07-13T14:24:02Z

Any specific reason to make distinction between SKIP and SKIP PREFIX?

I assume, that if a.b.c is "object", that if we set SKIP a.b.c, user may want to skip it as whole, basically behavior of SKIP PREFIX.

Avogar · 2024-07-15T10:19:05Z

I assume, that if a.b.c is "object", that if we set SKIP a.b.c, user may want to skip it as whole, basically behavior of SKIP PREFIX.

Yes, this is a good remark. It will be better to combine these 2

…ata-type

…l ugs

docs/en/sql-reference/functions/json-functions.md

pkese · 2024-08-16T11:42:24Z

@Avogar congratulations. This is amazing.

lazharichir · 2024-08-16T11:50:03Z

I think I speak for everybody when I say this is a GREAT news!

Backport #66444 to 24.8: Implement new JSON data type.

otto-gebb · 2024-09-17T10:26:25Z

I would be thankful for a migration guide from the old experimental JSON type.

Avogar · 2024-09-17T10:51:45Z

I would be thankful for a migration guide from the old experimental JSON type.

Right now the only way is to do INSERT SELECT with casting old Object type to String. We have plans to support cast from Object type to new JSON and will try to support ALTER between them (see all plans here: #68428)

franz101 · 2024-09-23T13:58:31Z

Amazing PR! Is there benchmark to compare the two versions?

Avogar · 2024-09-24T11:28:23Z

Is there benchmark to compare the two versions?

Right now we don't have such benchmark. But we advise not to use old Object type because it's deprecated and won't be supported anymore (also it has known bugs that won't be fixed).

Avogar added 6 commits July 3, 2024 15:36

Merge branch 'refactor-json-extract' of github.com:Avogar/ClickHouse …

4b8da7b

…into json-data-type

Merge branch 'refactor-json-extract' of github.com:Avogar/ClickHouse …

7322e12

…into json-data-type

Implement new JSON data type

dfc3db2

Small clean up

fb4317f

Add documentation

2b28323

Merge branch 'master' of github.com:ClickHouse/ClickHouse into json-d…

4848ad3

…ata-type

Avogar commented Jul 12, 2024

View reviewed changes

robot-clickhouse added the pr-feature Pull request with new product feature label Jul 12, 2024

antonio2368 self-assigned this Jul 12, 2024

Avogar added 5 commits July 12, 2024 15:15

Add more comments

4ad6597

Fix style

83037f5

Fix build

8394c8e

Fix compound identifier parser

b77cfc2

Fix clickhouse-format

11d56a0

UnamedRus mentioned this pull request Jul 13, 2024

SQL:2023 support matrix for ClickHouse #48388

Open

Avogar and others added 11 commits July 15, 2024 14:46

Unify SKIP and SKIP PREFIX hints, improve JSON parsing

43d86f9

Fix JSON type name creation

283de9d

Update documentation

941898a

Avoid calling type->getName

47e3e99

Merge branch 'master' of github.com:ClickHouse/ClickHouse into json-d…

0ef65fb

…ata-type

Fix build and JSON getName() method

094a1aa

Add tests, docs, implement new syntax sugar for Array(JSON), fix smal…

519494a

…l ugs

Merge branch 'master' into json-data-type

74670e7

Fix build and style

184405f

Fix style

6e7b5e7

Fix build

1ce13df

Avogar mentioned this pull request Aug 15, 2024

[Umbrella] JSON type improvements #68428

Open

56 tasks

Avogar and others added 3 commits August 15, 2024 20:55

Fix comment

bf44d17

Fix style

182c00e

Update tests

db691e4

PedroTadim reviewed Aug 16, 2024

View reviewed changes

docs/en/sql-reference/functions/json-functions.md Show resolved Hide resolved

Avogar added this pull request to the merge queue Aug 16, 2024

Merged via the queue into ClickHouse:master with commit 39bc050 Aug 16, 2024

Avogar deleted the json-data-type branch August 16, 2024 11:40

Avogar added the v24.8-must-backport label Aug 16, 2024

robot-ch-test-poll added the pr-synced-to-cloud The PR is synced to the cloud repo label Aug 16, 2024

robot-clickhouse-ci-1 mentioned this pull request Aug 16, 2024

Cherry pick #66444 to 24.8: Implement new JSON data type. #68448

Merged

robot-clickhouse added a commit that referenced this pull request Aug 16, 2024

Backport #66444 to 24.8: Implement new JSON data type.

387d6a8

robot-clickhouse-ci-2 mentioned this pull request Aug 16, 2024

Backport #66444 to 24.8: Implement new JSON data type. #68450

Merged

robot-ch-test-poll1 added the pr-backports-created Backport PRs are successfully created, it won't be processed by CI script anymore label Aug 16, 2024

robot-clickhouse added the pr-backports-created-cloud deprecated label, NOOP label Aug 16, 2024

robot-ch-test-poll4 added a commit that referenced this pull request Aug 16, 2024

Merge pull request #68450 from ClickHouse/backport/24.8/66444

1b8145b

Backport #66444 to 24.8: Implement new JSON data type.

rschu1ze mentioned this pull request Aug 19, 2024

Fix build with -DENABLE_LIBRARIES=0 #68527

Merged

nikitamikhaylov mentioned this pull request Aug 21, 2024

New JSON-type fuzzing proposal #68676

Open

nikitamikhaylov added the json Issues and pull-requests related to the new JSON data type label Aug 21, 2024

adamyeats mentioned this pull request Aug 30, 2024

Disable TestMutateResponse and TestConvertJSON for now grafana/clickhouse-datasource#967

Merged

pugachevdmitry mentioned this pull request Mar 31, 2026

Add Sparkbar aggregate function combinator #101352

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement new JSON data type.#66444

Implement new JSON data type.#66444
Avogar merged 91 commits intoClickHouse:masterfrom
Avogar:json-data-type

Avogar commented Jul 12, 2024 •

edited

Loading

Uh oh!

Avogar commented Jul 12, 2024

Uh oh!

Avogar Jul 12, 2024

Uh oh!

robot-clickhouse-ci-2 commented Jul 12, 2024 •

edited by robot-clickhouse

Loading

Uh oh!

UnamedRus commented Jul 13, 2024

Uh oh!

Avogar commented Jul 15, 2024

Uh oh!

Uh oh!

pkese commented Aug 16, 2024

Uh oh!

lazharichir commented Aug 16, 2024

Uh oh!

otto-gebb commented Sep 17, 2024

Uh oh!

Avogar commented Sep 17, 2024 •

edited

Loading

Uh oh!

franz101 commented Sep 23, 2024

Uh oh!

Avogar commented Sep 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

Conversation

Avogar commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Documentation entry for user-facing changes

JSON type

Creating JSON

Reading JSON paths as subcolumns

Reading JSON sub-objects as subcolumns

Handling arrays of JSON objects

CI Settings (Only check the boxes if you know what you are doing):

Uh oh!

Avogar commented Jul 12, 2024

Uh oh!

Avogar Jul 12, 2024

Choose a reason for hiding this comment

Uh oh!

robot-clickhouse-ci-2 commented Jul 12, 2024 • edited by robot-clickhouse Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

UnamedRus commented Jul 13, 2024

Uh oh!

Avogar commented Jul 15, 2024

Uh oh!

Uh oh!

pkese commented Aug 16, 2024

Uh oh!

lazharichir commented Aug 16, 2024

Uh oh!

otto-gebb commented Sep 17, 2024

Uh oh!

Avogar commented Sep 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

franz101 commented Sep 23, 2024

Uh oh!

Avogar commented Sep 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

Avogar commented Jul 12, 2024 •

edited

Loading

robot-clickhouse-ci-2 commented Jul 12, 2024 •

edited by robot-clickhouse

Loading

Avogar commented Sep 17, 2024 •

edited

Loading