Different serialization/deserialization rules

[klemenpeganc]

Hi!
We have a Date class which is an integer under the hood. Writing to json, we call a format() function on it which converts it to a human readable date (int: 2459963, human readable date: 18-01-2023). To read in the json, we take in the human-readable date, the expected format and convert it to the integer date. Is there any possibility in the library to accommodate for that?

Right now, we are only able to write the object to json...

template<> struct glz::meta<Metadata>
{
    using T = Metadata;
    static constexpr auto value = object("date", [](auto&& self) { return self.date.format("Y-M-D"); });
};

Like I said, this works when writing to json, but where and if even possible can I provide a definition on how to read in the json?

[mwalcott3]

I don't think this is documented yet but you can fully specialize or partial template specialize from_json and to_json for your custom type. An example of this can be seen in the Eigen matrix stuff here https://github.com/stephenberry/glaze/blob/main/include/glaze/ext/eigen.hpp

I think @stephenberry was planning on providing some more details/background on this.

[stephenberry]

@klemenpeganc

To explain @mwalcott3 answer further:

This kind of custom reading/writing is best handled by implementing your own from_json and to_json specializations within the glz::detail namespace.

Here is a very simplified example of your problem:

// custom type handling
struct date
{
   uint64_t data;
   std::string human_readable;
};

template <>
struct glz::meta<date>
{
   using T = date;
   static constexpr auto value = object("date", &T::human_readable);
};

namespace glz::detail
{
   template <>
   struct from_json<date>
   {
      template <auto Opts>
      static void op(date& value, auto&&... args)
      {
         read<json>::op<Opts>(value.human_readable, args...);
         value.data = std::stoi(value.human_readable);
      }
   };

   template <>
   struct to_json<date>
   {
      template <auto Opts>
      static void op(date& value, auto&&... args) noexcept
      {
         value.human_readable = std::to_string(value.data);
         write<json>::op<Opts>(value.human_readable, args...);
      }
   };
}

suite date_test = []
{
   "date"_test = [] {
      date d{};
      d.data = 55;
      
      std::string s{};
      glz::write_json(d, s);
      
      expect(s == R"("55")");
      
      d.data = 0;
      glz::read_json(d, s);
      expect(d.data == 55);
   };
};

[stephenberry]

This method of specialization is really powerful and lets you develop any sort of custom data conversion, but it does require learning some of the internal behavior of the library.

The templated Opts parameter contains the compile time options. The args... can be broken out into the runtime context (runtime options), iterators, and the buffer index when reading.

If you have more questions concerning custom serialization, be sure to ask!

[klemenpeganc]

This works really well, but I have a question. Is it possible to for example if std::stoi throws, to fail the deserialization and report it in the error code? Something like:

template <auto Opts>
      static void op(date& value, auto&&... args)
      {
         read<json>::op<Opts>(value.human_readable, args...);
         try{
         value.data = std::stoi(value.human_readable);
         } catch(std::invalid_argument& exception){
        // transmit error message, fail deserialization
         }
      }

[stephenberry]

Yes, you can certainly add a try-catch and set the glaze error, or you could just have a try-catch at a higher level.

If you wanted to set the glaze context error here, it would look like:

template <auto Opts>
static void op(date& value, is_context auto&& ctx, auto&&...) noexcept
{
   read<json>::op<Opts>(value.human_readable, ctx, args...);
   try {
      value.data = std::stoi(value.human_readable);
   } catch(std::invalid_argument& exception){
        // transmit error message, fail deserialization
       ctx.error = error_code::parse_number_failure;
   }
}

By setting the ctx.error here the rest of glaze will check this error and short circuit the parsing and you can handle the error as you would any other glaze error.