Skip to content

Add and export getSchema function #363

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

Merged
merged 7 commits into from
Apr 14, 2023
Merged

Add and export getSchema function #363

merged 7 commits into from
Apr 14, 2023

Conversation

annie
Copy link
Contributor

@annie annie commented Apr 14, 2023

This PR adds a getSchema function, building on a suggestion from Mike. This function conditionally infers a schema depending on whether or not a valid one exists on the source, combines the schema with any saved type assertions, and determines whether or not the source data needs to be coerced.

We will use getSchema in both __table and in the table schema tasks in the worker (I'll update https://github.com/observablehq/observablehq/pull/11496 to use this function), and thereby unify the two paths that we currently have for type inference.

I also added a missing unit test for type assertion in __table, as well as some tests for getSchema.

@annie
Copy link
Contributor Author

annie commented Apr 14, 2023

hm on second thought, maybe we should handle type assertions outside of getSchema, because it's a pain to have to pass around operations.types in the worker.

src/table.js Outdated
schema = inferSchema(source, isQueryResultSetColumns(columns) ? columns : undefined);
return {schema, shouldCoerce: true};
}
return {schema, shouldCoerce: false};
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we should call this “inferred” instead of “shouldCoerce”? Because “inferred” makes a factual observation about how the schema was derived, whereas “shouldCoerce” implies that the caller should do something with the returned schema—and perhaps the caller wants to do something else?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good call, updated.

src/table.js Outdated
Comment on lines 636 to 638
const schemaInfo = getSchema(source);
let {columns} = source;
let {schema, inferred} = schemaInfo;
Copy link
Member

@mbostock mbostock Apr 14, 2023

Choose a reason for hiding this comment

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

Minor simplification:

Suggested change
const schemaInfo = getSchema(source);
let {columns} = source;
let {schema, inferred} = schemaInfo;
let {columns} = source;
let {schema, inferred} = getSchema(source);

Also: I don’t think we should fix it now, but there’s a latent bug below where where we’re assuming that if source.columns is truthy, it’s a valid QueryResultSetColumns. That’s because this function is trying to preserve the same shape of output as the input; so, if the input had a source.columns, we return a result.columns. I don’t think we need to do that; we could just always return a result.schema instead, now that we’re inferring a schema as needed. But again, reasonable to do that as a separate change to minimize risk since it’s not directly related to this PR’s objective.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm yeah, now that .schema is always defined, do we even need to return .columns from this function or can we just remove it? or would that be a breaking change, since we export __table from stdlib?

Copy link
Member

Choose a reason for hiding this comment

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

Right, I meant I think that __table can always return .schema (and never .columns). I don’t think that would be breaking… 🤷

@annie annie merged commit 76d8919 into main Apr 14, 2023
@annie annie deleted the annie/get-schema branch April 14, 2023 21:46
@annie annie mentioned this pull request Apr 20, 2023
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