Seamless serialization of existing Rust structs

[jmillan]

Having an existing Rust struct which is also represented in the flatbuffers schema and thus in the autogenerated code.., is there any derive or traits we can implement in our struct so it can seamlessly serialize it into the builder, rather than having to manually convert from our struct to the one created by the autogenerated code?

Imagine a simple struct like:

struct DominantSpeakerNotification {
    producer_id: ProducerId,
}

Which has an analogous flatbuffers table which leads to the autogenerated code:

pub struct DominantSpeakerNotification {
    pub producer_id: ::planus::alloc::string::String,
}

Is there any derive or trait we could implement to serialize our DominantSpeakerNotification into the builder?

[TethysSvensson]

We could probably implement this, but I am very hesitant to implement custom attributes if we can avoid it.

Depending on your performance and organizational requirements, some of these work-arounds might suit your particular needs:

• Use the type generated by planus through-out your code and get rid of your own type
• Implement From and Into between the types
• Ignore the generated DominantSpeakerNotification and exclusively use the DominantSpeakerNotificationRef and DominantSpeakerNotificationBuilder types.

At my work we use a combination of these approaches, though we try to use the first one as much as possible.

If these work-arounds does not work for your use-case, could you expand a bit more upon what you need and why?

I'd love to support as many use-cases as possible, but I don't think I will add features without understanding the situations where those features are needed.

[nazar-pc]

Big challenge with Planus (and Flatbuffers in general) is that generated types do not contain documentation and do not allow us to have more fine-grained type. For instance, above ProducerId is actually struct ProducerId(::uuid::Uuid) with serde::{Seriaize,Deserialize} and some other stuff derived.

On Flatbuffers level right now it is just String, which is both heap-allocated and does not have any semantic meaning to it.

With Planus generated data structures end up being something like Box<HashMap<String, Box<HashSet<String>>>, which is A LOT of unnecessary allocations.

[TethysSvensson]

@nazar-pc We support docstrings in planus, which mitigates the issue you mentioned a bit. However you are right that we do not allow the level of documentation you would get otherwise.

[TethysSvensson]

Regarding the heap allocations, I would suggest that you use a [byte: 16] field, however planus does not currently support arrays. We would definitely be open to changing that though.

[jmillan]

exclusively use the DominantSpeakerNotificationRef and DominantSpeakerNotificationBuilder types

There is no DominantSpeakerNotificationBuilder type in the created body. Do you mean using DominiantSpeakerNotification::create() method?

[TethysSvensson]

We should really get around to making a new release...

On the current main branch there is a builder 😊