[Variant] Introduce `parquet-variant-json` crate #7862

alamb · 2025-07-03T19:10:36Z

Which issue does this PR close?

We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax.

Closes [Variant] Move JSON related functionality to different crate. #7800
Closes [Variant] feat: Add optional serde_json dependency of parquet-variant #7845
Closes [Variant] make serde_json an optional dependency of parquet-variant #7775

Rationale for this change

Now that we have the basic json conversion functionality complete thanks to @harshmotw-db ❤️ ❤️ ❤️ in

[VARIANT] Add support for the json_to_variant API #7783

I would like to move all the json related code into its own crate to keep the functionality clean and clear

What changes are included in this PR?

Move to_json and from_json into a new parquet-variant-json crate where we can continue to iterate
Added new crate to CI jobs

Are these changes tested?

CI

Are there any user-facing changes?

If there are user-facing changes then we may require documentation to be updated before approving the PR.

If there are any breaking changes to public APIs, please call them out.

alamb · 2025-07-03T19:12:10Z

parquet-variant/tests/test_json_to_variant.rs

@@ -1,552 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one


I moved these tests into a mod test next to the relevant code

alamb · 2025-07-03T19:12:18Z

parquet-variant/src/from_json.rs

@@ -1,151 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one


Moves to new crate

alamb · 2025-07-03T19:12:38Z

parquet-variant/examples/variant_from_json_examples.rs

@@ -1,50 +0,0 @@
-// Licensed to the Apache Software Foundation (ASF) under one


This example duplicated the doc example on from_json so I removed it entirely

alamb · 2025-07-05T11:34:50Z

@harshmotw-db or @scovich or @friendlymatthew -- could i trouble one of you for a review of this PR?

scovich · 2025-07-05T14:07:05Z

parquet-variant-json/Cargo.toml

+arrow-schema = { workspace = true }
+parquet-variant = { path = "../parquet-variant" }
+chrono = { workspace = true }
+serde_json = "1.0"


Idea being, this new crate can take an unapologetic dependency on serde-json, right?

scovich · 2025-07-05T14:07:54Z

parquet-variant-json/src/from_json.rs

Any changes in this file? Or just code movement that github didn't detect?

I presume it's because this PR adds some tests to this file. Moving the tests to a different file should fix it.

scovich · 2025-07-05T14:08:33Z

parquet-variant-json/src/from_json.rs

+#[cfg(test)]
+mod test {


Thatsalottatests... move to from_json/test.rs while we're at it?

I think it is more standard to put in the same module as the code being tested. I prefer it this way but I think it would be fine to move it to a different file if you want

Interesting.. I didn't have any intuition that inline vs. out of line test modules were meaningfully different?

#[cfg(test)] mod tests { ... }

vs.

#[cfg(test)] mod tests;

I think it is a matter of convention / preference -- I don't think there is any technical difference

If you strongly prefer an out of line test module I will change it

I don't see any other out of line test modules, so we should probably follow the existing convention?
(if we were going to split one out, I'd probably start with the 2k+ LoC in the builder.rs test module)

scovich · 2025-07-05T14:51:01Z

parquet-variant-json/src/to_json.rs

 #[cfg(test)]
 mod tests {


again... to_json/tests.rs while we're at it?

scovich · 2025-07-05T14:56:25Z

parquet-variant-json/src/from_json.rs

+/// let json_result = variant_to_json_string(&variant)?;
+/// let json_value = variant_to_json_value(&variant)?;
+///
+/// let mut buffer = Vec::new();
+/// variant_to_json(&mut buffer, &variant)?;


What would you think of keeping variant_to_json and variant_to_json_string in the main crate? They have no dependency on serde-json, and IMO are useful in their own right.

I agree they are useful in their own right, but I think it is pretty confusing to have json functionality split across two crates. I suggest we move all the JSON stuff to a new crate and we can always put to_json back if a need arises

Every engine needs the ability to convert variant values to strings, in order to display query results:

SELECT v FROM t

And the string form of a variant column is the output of variant_to_json_string.

This is true regardless of which JSON library they might use (serde_json vs arrow-json vs. something else entirely), and also true even if they use no JSON library at all.

In other words,

we can always put to_json back if a need arises

... will happen the moment an engine actually tries to integrate with parquet-json and doesn't want to take on a serde-json dependency. The fact that this PR tries to isolate the serde-json dependency to its own sub-crate is a claim that such engines exist.

it is pretty confusing to have json functionality split across two crates

JSON functionality (as in, parsing and manipulating JSON trees) is different from converting variant values to strings, even if it so happens that the string form is a JSON value literal?

What if we drop variant_to_json_string from the public API, and just impl Display for Variant instead? Anything fancier would require a json library.

What if we drop variant_to_json_string from the public API, and just impl Display for Variant instead? Anything fancier would require a json library.

I think this sounds like a good idea to me.

What do you think @harshmotw-db ? I can make the change if we are agreed (though this PR is getting big as it is)

I could do it in this PR or a follow on one

Hmm. I didn't notice before, but the to-string logic relies on serde_json::to_string for proper JSON string escaping. So the code really is tied to serde_json crate.

Further, serde_json::to_string is fallible, which would not play well with std::fmt::Error used by impl Display:

This type does not support transmission of an error other than that an error occurred. This is because, despite the existence of this error, string formatting is considered an infallible operation. fmt() implementors should not return this Error unless they received it from their Formatter. The only time your code should create a new instance of this error is when implementing fmt::Write, in order to cancel the formatting operation when writing to the underlying stream fails.

Probably better to take this as a follow-up item...

harshmotw-db

LGTM, thanks!

…-json

alamb · 2025-07-08T20:18:28Z

Let's go with this one and then refactor as needed

alamb · 2025-07-08T20:18:57Z

Thank you again @scovich @friendlymatthew and @harshmotw-db for the reviews

@alamb

…s of JSON strings to and from Variants (#7884) # Which issue does this PR close? We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. - Closes #7883. # Rationale for this change Explained in the ticket. **Note:** This PR will go through changes once [this PR](#7862) is merged. # What changes are included in this PR? This PR introduces two new functions `batch_json_string_to_variant` and `batch_variant_to_json_string` which can be used to transform batches of JSON strings to batches of Variant structs and vice versa. This PR attempts to implement `batch_variant_to_json_string` in a zero-copy way (@alamb see if you agree) since `variant_to_json` allows an input implementing a `Write` interface. `batch_json_string_to_variant` should also eventually be zero-copy once [this issue](#7805) is resolved. # Are these changes tested? Simple unit tests since the underlying functions have already been tested. # Are there any user-facing changes? Yes, it introduces the `batch_json_string_to_variant` and `batch_variant_to_json_string` APIs in a new crate. --------- Co-authored-by: Andrew Lamb <[email protected]>

alamb added 3 commits July 3, 2025 14:49

[Variant] Introduce parquet-variant-json crate

c4cd8d0

update

2d959ec

Update dependencies, move code

0b5d108

github-actions bot added the parquet Changes to the parquet crate label Jul 3, 2025

alamb mentioned this pull request Jul 3, 2025

[Variant] feat: Add optional serde_json dependency of parquet-variant #7845

Closed

alamb commented Jul 3, 2025

View reviewed changes

remove unused

d491093

alamb mentioned this pull request Jul 3, 2025

[Variant] Move JSON related functionality to different crate. #7800

Closed

scovich reviewed Jul 5, 2025

View reviewed changes

harshmotw-db approved these changes Jul 7, 2025

View reviewed changes

Merge remote-tracking branch 'apache/main' into alamb/parquet-variant…

00e6747

…-json

friendlymatthew approved these changes Jul 8, 2025

View reviewed changes

harshmotw-db mentioned this pull request Jul 8, 2025

[Variant] Introduce parquet-variant-compute crate to transform batches of JSON strings to and from Variants #7884

Merged

alamb merged commit 9246872 into apache:main Jul 8, 2025
35 of 36 checks passed

alamb deleted the alamb/parquet-variant-json branch July 8, 2025 20:18

		@@ -1,552 +0,0 @@
		// Licensed to the Apache Software Foundation (ASF) under one

		@@ -1,151 +0,0 @@
		// Licensed to the Apache Software Foundation (ASF) under one

		@@ -1,50 +0,0 @@
		// Licensed to the Apache Software Foundation (ASF) under one

[Variant] Introduce parquet-variant-json crate #7862

[Variant] Introduce parquet-variant-json crate #7862

Uh oh!

Conversation

alamb commented Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alamb commented Jul 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scovich Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alamb Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scovich Jul 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

harshmotw-db left a comment

Choose a reason for hiding this comment

Uh oh!

alamb commented Jul 8, 2025

Uh oh!

Uh oh!

alamb commented Jul 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[Variant] Introduce `parquet-variant-json` crate #7862

[Variant] Introduce `parquet-variant-json` crate #7862

alamb commented Jul 3, 2025 •

edited

Loading

scovich Jul 7, 2025 •

edited

Loading

alamb Jul 8, 2025 •

edited

Loading

scovich Jul 8, 2025 •

edited

Loading