Simplify Variant shredding and refactor for clarity #461

rdblue · 2024-10-20T22:17:19Z

Rationale for this change

Updating the Variant and shredding specs from a thorough review.

What changes are included in this PR?

Spec updates, mostly to the shredding spec to minimize it and make it clear. This also attempts to make the variant spec more consistent (for example, by using value in both).

Removes object and array in favor of always using typed_value
Makes list element and object field groups required to avoid unnecessary null cases
Separates cases for primitives, arrays, and objects
Adds individual examples for primitives, arrays, and objects
Adds Variant to Parquet type mapping for shredded columns
Clarifies that metadata must be valid for all variant values without modification
Updates reconstruction algorithm to be more pythonic

Do these changes have PoC implementations?

No.

VariantEncoding.md

VariantShredding.md

rdblue · 2024-10-20T22:24:32Z

VariantShredding.md

-We extract all homogenous data items of a certain path into `typed_value`, and set aside incompatible data items in `variant_value`.
-Intuitively, incompatibilities within the same path may occur because we store the shredding schema per Parquet file, and each file can contain several row groups.
-Selecting a type for each field that is acceptable for all rows would be impractical because it would require buffering the contents of an entire file before writing.
+All fields for a variant, whether shredded or not, must be present in the metadata.


This may be controversial. I'm trying to say that you should not need to modify the metadata when reading. The reconstructed object should be able to use the stored metadata without adding fields.

I'm a little confused. When the field is not shredded, we will not have metadata for it, right? When it's getting shredded, then it will be like a column and we will generate metadata so it can be used for filtering/pruning?

@sfc-gh-aixu, this is saying that when writing, the metadata for a shredded value and the metadata for a non-shredded value should be identical. Writers should not alter the metadata by removing shredded field names so that readers do not need to rewrite the metadata (and values) to add it back.

For example, consider an event that looks like this:

{ "id": 102, "event_type": "signup", "event_timestamp": "2024-10-21T20:06:34.198724", "payload": { "a": 1, "b": 2 } }

And a shredding schema:

optional group event (VARIANT) { required binary metadata; optional binary value; optional group typed_value { required group event_type { optional binary value; optional binary typed_value (STRING); } required group event_timestamp { optional binary value; optional int64 typed_value (TIMESTAMP(true, MICROS)); } } }

The top-level event_type and event_timestamp fields are shredded. But this is saying that the Variant metadata must include those field names. That ensure that the existing binary metadata can be returned to the engine without adding event_type and event_timestamp fields when merging those fields into the top-level Variant value when the entire Variant is projected.

Thanks for detailed explanation. Later I realize this is about variant metadata and what I was talking about was column metadata (stats).

I get what you are saying: when the entire Variant is projected, we need to reconstruct the original value and metadata by merging back the shredded fields if the metadata after shredding excludes the shredded fields.

That makes sense to me to reduce the metadata reconstruction on the read side.

VariantEncoding.md

sfc-gh-saya · 2024-10-22T20:36:04Z

VariantShredding.md


-Similarly the elements of an `array` must be a group containing one or more of `object`, `array`, `typed_value` or `variant_value`.
+Each shredded field is represented as a required group that contains a `variant_value` and a `typed_value` field.


Why each shredded field should be a required group is not clear to me. If fields were allowed to be optional, that would be another way of indicating non-existence of fields.

The primary purpose is to reduce the number of cases that implementers have to deal with. If all of the cases can be expressed with 2 optional fields rather than 2 optional fields inside an optional group, then the group should be required to simplify as much as possible.

In addition, every level in Parquet that is optional introduces another repetition/definition level. That adds up quickly with nested structures and ends up taking unnecessary space.

VariantShredding.md

VariantEncoding.md

VariantShredding.md

rdblue · 2024-10-24T20:50:13Z

VariantShredding.md

-The `typed_value` field may be any type that has a corresponding Variant type.
-For each value in the data, at most one of the `typed_value` and `variant_value` may be non-null.
-A writer may omit either field, which is equivalent to all rows being null.
+If both fields are non-null and either is not an object, the value is invalid. Readers must either fail or return the `typed_value`.


@RussellSpitzer and @gene-db, this could use some attention.

Here, if both value and typed_value are non-null I initially thought it made more sense to prefer value because it doesn't need to be re-encoded and may have been coerced by an engine to the shredded type.

However, this conflicts with object fields, where the value of typed_value is preferred so that data skipping is correct. If the object's value could contains a field that conflicts with a sub-field's typed_value there is no way of knowing from field stats. If we preferred the field value stored in the object's value then data skipping could be out of sync with the value returned in the case of a conflict.

the value is invalid

Suggested change

If both fields are non-null and either is not an object, the value is invalid. Readers must either fail or return the `typed_value`.

If both fields are non-null and either is not an object, the `value` is invalid. Readers must either fail or return the `typed_value`.

Why aren't we just being proscriptive here? Isn't this essentially saying you can duplicate a subfield-field between typed_value and value? Wouldn't it be safer to just say this cannot be done?

The problem is that readers won't actually implement restrictions like this and we can't fully prevent it. It is invalid for a writer to produce a value where value and typed_value conflict. But writer bugs happen and readers need to know what to do when they encounter that situation. Otherwise we would get different behaviors between readers that are processing the same data file.

It all comes down to end users -- if a writer bug produces data like this, readers will implement the ability to read because the data still exists and can be recovered. When that happens, we want to know how it is interpreted.

My take is if readers have bugs and produce invalid values, I'm not sure you can really trust most of the data at all (even metadata). It sounds like we are assuming 1 specific type of bug where readers accidentally forget to clear a field?

The point is not the bug. It is that we want to make it valid to read a projection without checking the value for bugs.

IMHO, trying to make the projection of an object to another one without having to read the value is too spark specific. For example, with keys "a" and "b" shredded, If I am casting {"a":2, "b":3, "c":4} to a struct with keys "a" and "b", I can easily imagine a cast semantic that will fail that cast and such a semantic will force us reading both the typed_value and value unless value is null.

I don't think I understand. If a and b are shredded, then there should be no fields with that name in value and the spec is stating that you don't need to check for them. That means all of the information needed to continue is in the shredded Parquet columns. That's not specific to Spark.

What I was trying to say is, if I am casting that field to a struct with "a" and "b" but "c" exists in value, then some engines will require that cast to fail, because the object with keys "a", "b" and "c" do not match the struct schema. Apparently, with spark such a cast succeeds by producing the struct with the subset of the keys that match the struct schema.

gene-db · 2024-10-25T02:00:44Z

VariantEncoding.md

+|---------------|-----------|----------------------------------------------------------|--------------------------------------|
+| Null type     | null      | `null`                                                   | `null`                               |
+| Boolean       | boolean   | `true` or `false`                                        | `true`                               |
+| Exact Numeric | number    | Digits in fraction must match scale, no exponent         | `34`, 34.00                          |


For exact numerics, we should allow truncating trailing zeros. For example, int8 value 1 and decimal(5,2) value 100 can both be represented as a JSON value 1.

Also, should the example be quoted to stay consistent?

Suggested change

| Exact Numeric | number | Digits in fraction must match scale, no exponent | `34`, 34.00 |

| Exact Numeric | number | Digits in fraction must match scale, no exponent | `34`, `34.00` |

I think the intent of considering Exact Numeric to be a single logical type is that we consider the int8 value 1 to be logically equivalent to decimal(5,2) with unscaled value 100. If that's the case, I think we'd want the produced JSON to be the same for both (probably 1 in both cases), and not recommend having the fraction match the scale.

@gene-db, @cashmand, these are concerns for the engine layer, not for storage. If Spark wants to automatically coerce between types that's fine, but the compromise that we talked about a couple months ago was to leave this out of the shredding spec and delegate the behavior to engines. Storage should always produce the data that was stored, without modification.

Yes, the engine should be the one concerned with changing types.

However, my original question was about this JSON representation wording. Currently, the Representation requirements for an Exact Numeric says the Digits in fraction must match scale. However, because the Exact Numeric is considered a logical type, the value 1 could be stored in the Variant as int8 1 or decimal(5,2) 100. Both of those would be the same numeric value, so we should allow truncating trailing zeros in the JSON representation, instead of requiring that the digits in the fraction match the scale.

@gene-db, the JSON representation should match the physical type as closely as possible. The reader can interpret the value however it chooses to, but a storage implementation should not discard the information.

If you want to produce 34 from 34.00 stored as decimal(9, 2) then the engine is responsible for casting the value to int8 and then producing JSON. The JSON representation for the original decimal(9, 2) value is 34.00.

@rdblue I am confused with this JSON chart then. If we are talking about "storage implementation", then are you expecting there is a "storage implementation" that is converting variant values to JSON? When will storage convert a variant value to a JSON string?

I originally thought this chart was trying to say, "When an engine wants to convert a variant value to a JSON string, here are the rules". Therefore, we should allow engines to cast integral decimals to integers before converting to JSON, as you already mentioned in your previous comment.

I think I agree with @gene-db on this. I think any json representation that has semantically the same meaning in JSON should be allowed. Translation to JSON is inherently lossy and I think trying to match semantics will be more error prone then it is worth (i.e. it should be a non-goal to expect it to be able to reconstruct the exact same variant from the proposed JSON representation).

I think maybe the wording or presentation of this mapping is a bit confusing.

I think we are on all on the same page of allowing engines to "normalize" the Variant value. For example, I think the Spark implementation already normalizes 1.00 to 1. There are also many optimizations and efficiency aspects with normalization, so we should not disallow that.

Maybe what this chart is trying to show is: "if you want to output a Variant value as a JSON string, this is the output format you should use". So, for numbers, the conversion should be like 1 or 1.23 (no quotes), not "1", or "1.23". If this chart was about the JSON output formatting, would that be more clear?

When an engine wants to convert a variant value to a JSON string, here are the rules

Yes, this is correct. We want a clear way to convert to a JSON string. However, the normalization needs to happen first. We don't want to specify that the JSON must be any more lossy than it already is.

Why would we require an engine to produce a normalized value?

Why would we require an engine to produce a normalized value?

At least for me, I don't think it is about "requiring" and engine to produce a normalized value first. I think if an engine is reading variant and converting it to JSON, it is possibly doing so through an internal representation so it can still apply operators on top of the JSON value and possibly even storing it as an internal representation. Conversion to a string is really only an end-user visible thing. So when I read this it seems to be requiring an engine to NOT normalize which could be hard to implement for some engines.

VariantShredding.md

cashmand · 2024-10-28T18:52:41Z

VariantShredding.md


-Dictionary IDs in a `variant_value` field refer to entries in the top-level `metadata` field.
+If a Variant is missing in a context where a value is required, readers must either fail or return a Variant null: basic type 0 (primitive) and physical type 0 (null).
+For example, if a Variant is required (like `measurement` above) and both `value` and `typed_value` are null, the returned `value` must be `00` (Variant null).


As mentioned in my previous comment, I think it would be invalid for measurement to have both value and typed_value be null, and should be an error. I don't understand why we're recommend returning variant null as an option.

This rule is to address the fact that arrays cannot contain a missing value. This is saying that if a value is required but both are null, the implementation must fill in a variant null.

This rule(both value being null should be interpreted as json-null) is valid only for top level variant and array elements? I wonder how a top level variant can be inserted as both value and typed_value being null if the top level field is required. That seems inconsistent. For arrays, it looks like we could also require value being variant encoded null(json null) rather than allowing both fields to be null.

@sfc-gh-saya, if the top-level field is required but both fields are null, then the reader must produce a variant null value, 00. We must state what happens in cases like this because it is possible for writers to produce them.

If the writers produce nulls for both value and typed_value , it's like a corrupted files and I feel it's reasonable for the readers to error out rather than give a default value.

@rdblue Shouldn't this always be an error? This looks like invalid shredded data.

Above in the chart, we say (value=null, typed_value=null) | The value is missing; only valid for shredded object fields. This means we can only have (null, null) for shredded object fields.

In other scenarios, shredding should never produce (null, null). If there was ever a required variant that is a variant-null, then the shredding scheme should produce (variant-null, null), and should never produce (null, null).

We could introduce more error cases, but I don't see much value in requiring this to be an error, but only when value and typed_value don't represent an object field. More error cases lead to more rejected data and it is simple to just define how to handle this case. That makes readers easier to implement.

VariantShredding.md

RussellSpitzer · 2024-11-05T20:47:57Z

VariantShredding.md

-At a high level, we replace the `value` field of the Variant Parquet group with one or more fields called `object`, `array`, `typed_value`, and `variant_value`.
-These represent a fixed schema suitable for constructing the full Variant value for each row.
+For example, the query `SELECT variant_get(event, '$.event_ts', 'timestamp') FROM tbl` only needs to load field `event_ts`, and shredding can enable columnar projection that ignores the rest of the `event` Variant.
+Similarly, for the query `SELECT * FROM tbl WHERE variant_get(event, '$.event_type', 'string') = 'signup'`, the `event_type` shredded column metadata can be used for skipping and to lazily load the rest of the Variant.


Suggested change

Similarly, for the query `SELECT * FROM tbl WHERE variant_get(event, '$.event_type', 'string') = 'signup'`, the `event_type` shredded column metadata can be used for skipping and to lazily load the rest of the Variant.

Similarly, for the query `SELECT * FROM tbl WHERE variant_get(event, '$.event_type', 'string') = 'signup'`, the `event_type` shredded column metadata can be used for skipping while the rest of the Variant is lazily loaded for matching pages.

VariantShredding.md

RussellSpitzer · 2024-11-05T22:47:26Z

VariantShredding.md

-# Data Skipping
+All elements of an array must be non-null because `array` elements in a Variant cannot be missing.
+That is, either `typed_value` or `value` (but not both) must be non-null.
+Null elements must be encoded in `value` as Variant null: basic type 0 (primitive) and physical type 0 (null).


just for consistency it was written as

`00` (Variant null).

Earlier in the doc but this is fine too

RussellSpitzer · 2024-11-05T23:06:55Z

VariantShredding.md

+| `{"error_msg": "malformed: ..."}`                                                  | `{"error_msg", "malformed: ..."}` | null          |                                |                                      |                              |                                    | Object with no shredding                      |
+| `"malformed: not an object"`                                                       | `malformed: not an object`        | null          |                                |                                      |                              |                                    | Not an object (stored as Variant string)      |
+| `{"event_ts": 1729794240241, "click": "_button"}`                                  | `{"click": "_button"}`            | non-null      | null                           | null                                 | null                         | 1729794240241                      | Field `event_type` is missing                 |
+| `{"event_type": null, "event_ts": 1729794954163}`                                  | null                              | non-null      | `00` (field exists, is null)   | null                                 | null                         | 1729794954163                      | Field `event_type` is present and is null     |


Some more requested examples,

Could we have where "event_ts" is a Date or something non transformable into a timestamp?
I assume this would make value be {"event_ts": "08-03-2025"} while typed_value would be null

I also wonder if we could do a single example for a doubly nested field showing where typed_value.address.value != null. All the examples here cover a primitive field being typed, so It may be nice to show the behavior with a object being typed.

{ Name Address { City ZIP (Shredded as INT but some values as String?) } }

I added most other examples, but I don't think that we need the nested example because it would make the table much larger. I also cover nesting in the next section specifically.

RussellSpitzer · 2024-11-05T23:10:47Z

VariantShredding.md


+The `typed_value` associated with any Variant `value` field can be any shredded type according to the rules above.


I don't think I understand this sentence, but I believe I understand the intent is that you can have objects or elements within arrays also shredded?

I think the tables above are easier for me to follow than the parquet schema below. I understand though if that's difficult to depict.

This is just saying that any time you have a value field, you can also have a typed_value field that might be any shredded type, like an array nested in a field or an object nested in an array.

RussellSpitzer · 2024-11-06T16:04:21Z

VariantShredding.md


-Consider the following example:
+Statistics for `typed_value` columns can be used for file, row group, or page skipping when `value` is always null (missing).


Do we need to specify "null" vs "variant null" I get a little confused sometimes in the doc.

Isn't "null (missing)" clear that it is not variant null? Missing is only used to mean one form of null in the text.

RussellSpitzer · 2024-11-06T16:34:40Z

VariantShredding.md

-  “not an object”
-]
-```
+When the corresponding `value` column is all nulls, all values must be the shredded `typed_value` field's type.


Sometimes we refer to the value as a column and sometimes as a field. Just wondering if we should take a pass to standardize unless there is another meaning i'm not following here.

I think I was referring to "value" as a Parquet column. All object variant fields should be referred to as "field".

it might be good to have this in a glossary at the top.

VariantShredding.md

aihuaxu

Thanks a lot for driving this for clarity. @rdblue

aihuaxu · 2025-02-03T21:35:46Z

VariantShredding.md

+| timestamp with time zone    | TIMESTAMP(true, MICROS|NANOS)     |
+| timestamp without time zone | TIMESTAMP(false, MICROS|NANOS)    |


nit: The code seems correct but the preview cuts off the words somehow.

I fixed this by adding separate columns for physical type and logical type annotation.

emkornfield

I think we should merge this and close on remaining open items in more focused PRs/Discussion:

Open issues I see, JSON conversion suggestions, I think should be less strong (i.e. recommendations but since this is an engine concern probably should not be part of the official spec, especially because it might be complicated for engines to implement full precision requirements when going through an in memory model of JSON before actually serializing).
https://github.com/apache/parquet-format/pull/461/files#r1819588055 has a few commentors and it isn't clear there is a resolution.
I think a glossary would help new readers distinguish between subtle concepts.

rdblue · 2025-02-05T20:47:47Z

Thanks to everyone for reviewing! I'll merge this tomorrow unless there are objections. I think to avoid confusion like #479, we should get this in and then close on any remaining issues.

gene-db

Thanks for simplifying and improving all of the shredding details!

rdblue · 2025-02-06T20:54:07Z

Thanks for all the reviews, everyone! I just merged this so that we can move forward with the next round of discussion.

…hredded` by default ### What changes were proposed in this pull request? Disable `spark.sql.variant.allowReadingShredded` by default ### Why are the changes needed? apache/parquet-format#461 made incompatible changes on the shredding spec, if Spark delivers the current shredding implementation as-is in Spark 4.0, additional migration/compatible efforts will be required in the future. ### Does this PR introduce _any_ user-facing change? No, variant is an unreleased feature. ### How was this patch tested? Pass GHA. ### Was this patch authored or co-authored using generative AI tooling? No. Closes #49874 from pan3793/SPARK-45891-followup. Authored-by: Cheng Pan <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]>

…hredded` by default ### What changes were proposed in this pull request? Disable `spark.sql.variant.allowReadingShredded` by default ### Why are the changes needed? apache/parquet-format#461 made incompatible changes on the shredding spec, if Spark delivers the current shredding implementation as-is in Spark 4.0, additional migration/compatible efforts will be required in the future. ### Does this PR introduce _any_ user-facing change? No, variant is an unreleased feature. ### How was this patch tested? Pass GHA. ### Was this patch authored or co-authored using generative AI tooling? No. Closes #49874 from pan3793/SPARK-45891-followup. Authored-by: Cheng Pan <[email protected]> Signed-off-by: Dongjoon Hyun <[email protected]> (cherry picked from commit ba3e271) Signed-off-by: Dongjoon Hyun <[email protected]>

rdblue force-pushed the variant-updates branch 2 times, most recently from c4b435f to 8352319 Compare October 20, 2024 22:22

rdblue commented Oct 20, 2024

View reviewed changes

VariantEncoding.md Show resolved Hide resolved

rdblue commented Oct 20, 2024

View reviewed changes

VariantShredding.md Show resolved Hide resolved

rdblue commented Oct 20, 2024

View reviewed changes

gene-db reviewed Oct 21, 2024

View reviewed changes

VariantEncoding.md Outdated Show resolved Hide resolved

rdblue mentioned this pull request Oct 21, 2024

GH-459: Add Variant logical type annotation #460

Merged

sfc-gh-saya reviewed Oct 22, 2024

View reviewed changes

RussellSpitzer reviewed Oct 24, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Oct 24, 2024

View reviewed changes

VariantShredding.md Show resolved Hide resolved

sfc-gh-saya reviewed Oct 24, 2024

View reviewed changes

VariantEncoding.md Show resolved Hide resolved

RussellSpitzer reviewed Oct 24, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Oct 24, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

rdblue commented Oct 24, 2024

View reviewed changes

rdblue changed the title ~~WIP: Current work on Variant specs~~ Simplify Variant shredding and refactor for clarity Oct 24, 2024

gene-db reviewed Oct 25, 2024

View reviewed changes

cashmand reviewed Oct 28, 2024

View reviewed changes

VariantShredding.md Show resolved Hide resolved

RussellSpitzer reviewed Nov 5, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Nov 5, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Nov 5, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

cashmand reviewed Nov 5, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Nov 5, 2024

View reviewed changes

RussellSpitzer reviewed Nov 6, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

RussellSpitzer reviewed Nov 6, 2024

View reviewed changes

VariantShredding.md Outdated Show resolved Hide resolved

rdblue added 16 commits February 3, 2025 09:21

Remove Option 2, which cannot be used because stats aren't trusted.

d964ddb

More updates to the Variant spec.

3d71786

Trim the intro

6662e19

Update the encoding to capture required/optional value.

111a626

Remove unnecessary required.

76c84ec

Use typed_value when there is a conflict.

b57cde1

Minor updates.

c0697cd

Clarify cases where a value is required but missing.

9f5d92d

Updates from reviews.

d77b25a

Update from latest review comments.

5d73863

Handle infinities and NaN in the JSON encoding.

bf7e825

Specify columns accessed by name, not position.

e0a4d54

Clarifications.

b86d2e2

Update reader requirements to be more strict.

6fe5510

Update requirements for value/typed_value conflicts.

e3ef208

Update Encoding.

0bb8b97

rdblue force-pushed the variant-updates branch from 9c283bc to 0bb8b97 Compare February 3, 2025 17:42

Update shredded Parquet types for new types.

741c115

aihuaxu approved these changes Feb 3, 2025

View reviewed changes

Fix types table.

a084f84

emkornfield approved these changes Feb 5, 2025

View reviewed changes

gene-db approved these changes Feb 6, 2025

View reviewed changes

cashmand approved these changes Feb 6, 2025

View reviewed changes

cashmand mentioned this pull request Feb 6, 2025

[VARIANT] Accept variantType RFC delta-io/delta#4096

Merged

5 tasks

rdblue merged commit 37b6e8b into apache:master Feb 6, 2025
4 checks passed

pan3793 mentioned this pull request Feb 11, 2025

[SPARK-45891][SQL][FOLLOWUP] Disable spark.sql.variant.allowReadingShredded by default apache/spark#49874

Closed


		Similarly the elements of an `array` must be a group containing one or more of `object`, `array`, `typed_value` or `variant_value`.
		Each shredded field is represented as a required group that contains a `variant_value` and a `typed_value` field.

	If both fields are non-null and either is not an object, the value is invalid. Readers must either fail or return the `typed_value`.
	If both fields are non-null and either is not an object, the `value` is invalid. Readers must either fail or return the `typed_value`.

	\| Exact Numeric \| number \| Digits in fraction must match scale, no exponent \| `34`, 34.00 \|
	\| Exact Numeric \| number \| Digits in fraction must match scale, no exponent \| `34`, `34.00` \|

	Similarly, for the query `SELECT * FROM tbl WHERE variant_get(event, '$.event_type', 'string') = 'signup'`, the `event_type` shredded column metadata can be used for skipping and to lazily load the rest of the Variant.
	Similarly, for the query `SELECT * FROM tbl WHERE variant_get(event, '$.event_type', 'string') = 'signup'`, the `event_type` shredded column metadata can be used for skipping while the rest of the Variant is lazily loaded for matching pages.


		The `typed_value` associated with any Variant `value` field can be any shredded type according to the rules above.


		Consider the following example:
		Statistics for `typed_value` columns can be used for file, row group, or page skipping when `value` is always null (missing).

		\| timestamp with time zone \| TIMESTAMP(true, MICROS\|NANOS) \|
		\| timestamp without time zone \| TIMESTAMP(false, MICROS\|NANOS) \|

Simplify Variant shredding and refactor for clarity #461

Simplify Variant shredding and refactor for clarity #461

Conversation

rdblue commented Oct 20, 2024 • edited Loading

Rationale for this change

What changes are included in this PR?

Do these changes have PoC implementations?

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rdblue Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aihuaxu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emkornfield left a comment

Choose a reason for hiding this comment

rdblue commented Feb 5, 2025

gene-db left a comment

Choose a reason for hiding this comment

rdblue commented Feb 6, 2025

rdblue commented Oct 20, 2024 •

edited

Loading

rdblue Oct 24, 2024 •

edited

Loading