Serde deserialize support

[farazfazli]

Closes #203. WIP.

[farazfazli]

I believe the struct fields that aren't being deserialized will have to be wrapped with Option, to ensure that deserialization is performed properly. We can't use #[serde(skip_deserializing)] because certain types which lack a default implementation are defined in a different package.

One example is of this is OffsetDateTime.

[farazfazli]

@LouisGariepy Please let me know your thoughts on this whenever you get a chance.

[LouisGariepy]

Hi Faraz! Sorry for the delay.

I do believe it would be possible to implement Deserialize for the "owned" variant of generated types.

I'm not sure about this comment though

I believe the struct fields that aren't being deserialized will have to be wrapped with Option, to ensure that deserialization is performed properly. We can't use #[serde(skip_deserializing)] because certain types which lack a default implementation are defined in a different package.

Could you clarify what you mean by "fields that aren't being deserialized"? Do you mean that you would want you api to accept missing fields?

In the structs generated by Cornucopia, Option means that the attribute is nullable in the database. We can't make fields optional based on whether they are Default or not.

In my opinion, the Serialize and Deserialize implementations are provided as conveniences for simple cases. If you need more complex Serialization/Deserialization (for example, making some fields skippable during deserialization), you should consider:

1. Making a deserialization wrapper that handles the deserialization logic, or
2. Marking the relevant types as nullable in your database.

@farazfazli Maybe I'm misunderstood what you meant though. Please let me know and don't hesitate to correct me if that's the case.

Thanks for your contributions!

[Occuros]

Is this PR still considered?