Skip to content
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

Adds support for Ion 1.1 inline symbols to the system-level binary reader. #860

Merged
merged 1 commit into from
May 16, 2024

Conversation

tgregg
Copy link
Contributor

@tgregg tgregg commented May 15, 2024

Description of changes:

This requires checking with the "core" reader whether a symbol token was encoded as a SID or with inline text. Note: the system reader is not considered to be performance-critical.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Comment on lines +54 to +58
if (minor == 0) {
pendingIvmSids.add(SystemSymbols.ION_1_0_SID);
} else {
// TODO how should this be handled for Ion 1.1?
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how should this be handled for Ion 1.1?

I have some ideas, but I haven't checked them for feasibility w.r.t. backwards compatibility with existing public APIs.

We don't actually need the SID of the IVM. We just need some value that represents which version it is. I don't think we should re-use IonEncodingVersion for this, but we could create an internal-only VersionMarker enum or something like that.

Alternately, maybe we could say that the system reader doesn't give you IVMs as symbols—it requires registering an IVM listener just like the regular reader.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're on the same page here. I would like if we could avoid requiring the Ion 1.1 writer to recognize SIDs as IVMs, while still allowing IVMs to be propagated from the system reader to a user-level writer. We may have to add some extra logic / callback registration between the writer and system reader to make that work, but it should be doable.

Comment on lines +102 to +108
* It is the caller's responsibility to ensure {@link #hasAnnotations()} returns
* true before calling this method.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it easier to implement this way, or can we just say that the consumer will receive no values if there are no annotations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an internal API, so I'm happy to have a stricter contract that cuts down on extra branching.

@tgregg tgregg force-pushed the ion-11-system-inline-symbols branch from 20461ea to c5d9d4a Compare May 16, 2024 00:05
@tgregg tgregg merged commit 4167fa3 into ion-11-encoding May 16, 2024
16 of 17 checks passed
@tgregg tgregg deleted the ion-11-system-inline-symbols branch May 16, 2024 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants