Add flag to skip validation on read

[eslavich]

This PR adds a flag to asdf.open and fits_embed.AsdfInFits.open that disables validation on read, for situations when the file is already known to be valid and the user wishes to avoid the performance penalty of an unnecessary validation pass.

Resolves #565

[codecov]

Codecov Report

Merging #792 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #792   +/-   ##
=======================================
  Coverage   93.91%   93.91%           
=======================================
  Files          43       43           
  Lines        5043     5044    +1     
=======================================
+ Hits         4736     4737    +1     
  Misses        307      307           

Impacted Files	Coverage Δ
asdf/fits_embed.py	92.70% <ø> (ø)
asdf/asdf.py	92.83% <100.00%> (+0.01%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5f2b399...05a4eaa. Read the comment docs.

[perrygreenfield]

Is there ever anything written to this file path? I don't see it in the code below, but maybe there is some test magic going on that isn't apparent.

[eslavich]

Uhhhhh... waves hand vaguely this is not the tempfile you're looking for

[jdavies-st]

It looks like this validate_on_read=True flag doesn't change the anything by default, but can be switched to False and it will then not go through any schema validation? Is the use of the schema to deserialize the ASDF content into a python object separate from validation of the ASDF against the various schemas?

[perrygreenfield]

Looks straightforward and clear to me.

[eslavich]

It looks like this validate_on_read=True flag doesn't change the anything by default, but can be switched to False and it will then not go through any schema validation?

Yup! Well, it'll skip the main validation pass, anyway. The validator will still be used to fill in default values, but that pass doesn't check data types or anything.

Is the use of the schema to deserialize the ASDF content into a python object separate from validation of the ASDF against the various schemas?

AFAIK, if validation and filling defaults are both disabled, the schema isn't used at all.

[jdavies-st]

Ah, I see. So then only the CustomType subclass is used to turn the ASDF YAML into the custom python object?

[eslavich]

Right, and that matches to the YAML by tag, which is already known in both the file and the subclass, so the schema isn't consulted.

[perrygreenfield]

But tag code is still executed?

[jdavies-st]

Wow, I didn't realize the schemas were so superfluous. =)

[eslavich]

But tag code is still executed?

I made an interesting test: I deleted a bunch of core schemas and opened a file with validate_on_read=False and do_not_fill_defaults=True, and it opens and deserializes correctly without so much as a warning.

[perrygreenfield]

So the only subtlety is regarding defaults. In one case (using schemas), one has the attribute with a default value, but if validate_on_read=False, then the attribute is missing unless the tag code also handles defaults implicitly.

[perrygreenfield]

The more I see the implications, the less I like schemas handling defaults. But I may be having a brain short circuit...

[jdavies-st]

I agree that handling defaults is bad, as it makes data values depend on the vagaries of schemas. Just to save a few bytes.

And there's the whole issue of not being able to serialize None because that's the value that asdf uses to know whether or not to fill defaults.

[eslavich]

So the only subtlety is regarding defaults. In one case (using schemas), one has the attribute with a default value, but if validate_on_read=False, then the attribute is missing unless the tag code also handles defaults implicitly.

Actually, the defaults are still filled in. That happens on a separate pass through the tree that this PR doesn't impact. My next PR does combine those two passes when both validation and defaults are enabled, but even there the defaults are still filled in with validation disabled.

That said, I would love it if we could drop the defaults feature in 3.0. The more time I spend trying to figure out a sane procedure for choosing a default from a complex schema the more I suspect there isn't any such procedure. These schemas just aren't designed to provide a definitive answer to the question "what is the value of an annotation for this node?". IMO the default field should exist only as advice to people writing deserializers, and not be acted upon by asdf code. The type class seems like a more natural place to set defaults.