# Can't read old JLD2 file

**URL:** https://discourse.julialang.org/t/cant-read-old-jld2-file/20708
**Category:** Tooling
**Created:** [February 12, 2019, 4:02pm UTC](https://discourse.julialang.org/t/cant-read-old-jld2-file/20708 "2019-02-12T16:02:12Z")
**Posts on this page:** 1
**Showing post:** 10

<div class="post-metadata">

### Author: ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 19, 2019, 9:57am UTC](https://discourse.julialang.org/t/cant-read-old-jld2-file/20708/10 "2019-02-19T09:57:50Z")

</div>

> [@tobias.knopp](#):
>
> better support for compound datatypes which will improve the situation there

I disagree with this — I think the best solution is to support datatypes which have a native or near-native correspondence with what is supported by HDF5, and _require explicit conversion by the user for the rest_.

This seems like an unnecessary overhead, but making the mapping automatic is not a strategy that works well even in the medium run, as such mappings inevitable break down, sometimes silently (with no error, just corrupted data).

IMO this has been the source of a lot of grief for users who thought that they can just use JLD2 or similar as a fast, native, and reasonably robust data storage format. I think that there are two viable approaches:

1. emphemeral data one can regenerate at little cost: `Serialization.serialize` and friends or `Mmap.mmap`, depending on the details,

2. structured data that is costly to regenerate: map to something that is supported by HDF5, and for long-term storage write a lot of relevant metadata, including strings with explanations, and hope for the best.

---

_[View the full topic](https://discourse.julialang.org/t/cant-read-old-jld2-file/20708)._