Patch recursively

[dnsl48]

Hi, thank you for the great crate! It's really neat and is quite useful as it is!

I was wondering if I missed it in the docs and if not, whether you thought about adding support for recursive patches.

E.g. I have a DTO that contains a couple of other DTOs as fields. Each of those also implements "Patch" trait.
At the moment, when I call "into_patch_by_diff" for the top-level structure, it does correctly identify the changes in the included entities (as long as they implement PartialEq).
However, the top-level patch then includes the entire struct, not its own patch.

It would be neat to support included structs (that derive Patch even without PartialEq) to capture the specific changes in there. That would reduce the unnecessary data duplication in the multi-layered structs and open up better handling for structures with #[serde(flatten)] and #[diesel(embed)].

What do you think?

Code snippet for the use case

#[derive(Clone, Debug, Deserialize, Serialize, Patch)]
#[patch(attribute(derive(Serialize, Deserialize, Debug)))]
pub struct ProfileDTO {
    // meta
    #[patch(skip)]
    pub id: Uuid,

    #[serde(flatten)]
    #[patch(attribute(serde(flatten)))]
    pub identity_fields: ProfileIdentityFieldsDTO,

    #[serde(flatten)]
    #[patch(attribute(serde(flatten)))]
    pub contact_fields: ProfileContactFieldsDTO,
}

#[derive(Clone, Debug, Deserialize, Serialize, Patch, Eq, PartialEq)]
#[patch(attribute(derive(Serialize, Deserialize, Debug)))]
pub struct ProfileIdentityFieldsDTO {
    #[patch(attribute(serde(skip_serializing_if = "Option::is_none")))]
    pub first_name: Option<String>,

    #[patch(attribute(serde(skip_serializing_if = "Option::is_none")))]
    pub last_name: Option<String>,

    #[patch(attribute(serde(skip_serializing_if = "Option::is_none")))]
    pub middle_name: Option<String>,
}


#[derive(Clone, Debug, Deserialize, Serialize, Patch, Eq, PartialEq)]
#[patch(attribute(derive(Serialize, Deserialize, Debug)))]
pub struct ProfileContactFieldsDTO {
    #[patch(attribute(serde(skip_serializing_if = "Option::is_none")))]
    pub email: Option<String>,
    
    #[patch(attribute(serde(skip_serializing_if = "Option::is_none")))]
    pub phone_number: Option<String>,
}

[yanganto]

The original design avoid nesting Patch structure, and recursion was no under consideration. But now it is reasonable to have a feature of crate for this, if there is a using case.

[yanganto]

#[patch(flatten)] will need more design before implement, and we have #[patch(nesting)] now, this feature allow a patch inside another patch. I hope this can solve most your using case in quick.

[dnsl48]

@yanganto thank you for the quick response and thank you for the patch!
The nesting feature looks just like what I was thinking about. I am not too sure if we need the patch(flatten), or if it has enough value at this point.

I'm trying out the crate version 0.10.0

struct-patch = { version = "0.10.0", features = ["nesting"] }

However, I'm getting the following error:

error: proc-macro derive panicked
   --> app/src/api/routes/profile/schema.rs:131:48
    |
131 | #[derive(Clone, Debug, Deserialize, Serialize, Patch)]
    |                                                ^^^^^
    |
    = help: message: called `Result::unwrap()` on an `Err` value: Error("#[patch(nesting)] only work with `nesting` feature")

Looking at what may cause my issue, I've noticed that feature nesting in the struct-patch crate does not enable struct-patch-derive/nesting - https://github.com/yanganto/struct-patch/blob/main/struct-patch/Cargo.toml#L38

[yanganto]

Hi @dnsl48
Sorry about this, 0.10.1 enable the nesting feature of derive crate.
Thanks for reporting this.

[dnsl48]

@yanganto thank you for the quick follow-up!
Unfortunately, I'm stumbling across another error, which I am not too sure about.

I've put together a small example to show the error in this PR: #99

Basically, it's just saying "missing field" for any child field with a nested structure (deriving Patch).

[yanganto]

Hi @dnsl48
There are some cross feature conflict, so the patch did not implement correctly, so the error message said the field from #[patch(nesting)] was not implemented.

These are fixed in #100 and released in 0.10.2. Please try it again, thank for your patient

[dnsl48]

@yanganto Thank you so much! It all seems to be working like a charm! :)

[yanganto]

Thanks for providing your idea on top of struct-patch. Please kindly open issue or PR if you have any new idea on this.