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

Thawing var leads to error #143

Closed
aneilbaboo opened this issue Sep 30, 2021 · 3 comments
Closed

Thawing var leads to error #143

aneilbaboo opened this issue Sep 30, 2021 · 3 comments

Comments

@aneilbaboo
Copy link

aneilbaboo commented Sep 30, 2021

When freezing and thawing a nested structure, is there a way to turnoff metadata for one particular type?

I have a tree structure which includes clojure.lang.Var. As @atdixon pointed out here, thawing a Var results in an error when nippy attempts to apply metadata to it.

I know about *incl-metadata* and the option to freeze, but that forces me to turn of metadata persistence for all objects in a tree. Given that some classes like Var don't play well with metadata, it would be nice to have a way to provide a metadata exclusion list.

@ptaoussanis
Copy link
Member

@aneilbaboo Hi Aneil, thanks for the clear+motivated question 👍

A couple quick thoughts:

  • Seems it might be sensible to only auto-freeze metadata for IObjs? Would just want to investigate what the motivation actually is between Clojure having separate IMeta, IObj interfaces - it's not immediately obvious to me. PR welcome!

  • You should (untested) be able to setup a temporary workaround by manually extending the implementation detail taoensso.nippy/IFreezable2 to clojure.lang.Var, e.g.:

(extend-protocol taoensso.nippy/IFreezable2
    clojure.lang.Var
    (taoensso.nippy/-freeze-with-meta! [x data-output]
      (taoensso.nippy/-freeze-without-meta! x data-output)))

This basically instructs Nippy to handle clojure.lang.Var's -freeze-with-meta! with -freeze-without-meta!.

This would only be a temporary workaround since it's making use of an implementation detail (i.e. would be subject to breakage) - but the data produced by such freezing would be forward compatible.

I.e. the mechanism to achieve the goal is subject to breakage, but the resulting data would be safe (not subject to breakage).

As for providing a general option for turning off metadata persistence for specific types: am open to the idea in principle, but would want to first understand a little better what the common use cases would be. There's several different ways that this could be implemented - and there'd be differences in convenience, flexibility, and performance.

One obvious (and high-performance) way would be to just add a public fn to do something like the workaround above for a given class: i.e. just register an IFreezable2 implementation for the given class that just skips metadata.

An alternative that's more flexible but slower would be for *incl-metadata?* to support a predicate value, etc.

What's your specific use case for de/serializing Vars?

@aneilbaboo
Copy link
Author

aneilbaboo commented Oct 1, 2021

I like your suggestion of testing whether an object supports IObj before calling with-meta on it. Although there is no guarantee in the docs that IObj is necessary for successfully calling with-meta, the code shows with-meta is just a wrapper around it.

I'm saving dynamic variable bindings to regenerate later. I worked around this by saving symbol names instead. Thanks for the extend-protocol suggestion.

@ptaoussanis ptaoussanis changed the title Prevent including metadata on specific types? Thawing var leads to error Jul 27, 2023
@ptaoussanis
Copy link
Member

Closing, this will be addressed in next Nippy release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants