rharter / auto-value-moshi

AutoValue: Moshi Extension
Apache License 2.0
190 stars 25 forks source link

[Feature Request] Ability to ignore serialization / deserialization on certain properties #38

Closed vanniktech closed 8 years ago

vanniktech commented 8 years ago

Unfortunately we have a backend which is very restrictive. We are only allowed to send certain fields. Also there are fields which the server sends us but we're not allowed to send them back. On top of that we can't request a backend change.

API proposal:

@AutoValue
public abstract class MyAutoValue {
    @Json(name = "name") String name(); // Can be sent & received
    @Json(name = "foo") @SendOnly String foo(); // Will be used for serializing but not for deserializing
    @Json(name = "bar") @ReceiveOnly String bar(); // Will be used for deserializing but not for serializing
}

The annotations need to be defined from the consumers and the processor will just check for name equality. (Same way auto-value-redacted works)

If you're open for this, I'm more than happy to send a PR for this.

rharter commented 8 years ago

Thats an interesting consideration. I hadn't considered that you might want to serialize and deserialize differently, meaning you can't serialize the object and get the same object back. I have a few reservations about this.

First, I think the proposed terminology could be better. The JSON serialization doesn't really have anything to do with sending or receiving data, so I think that would be better as @SerializeOnly and @DeserializeOnly.

Secondly, I'm wondering whose job this is. Should this be supported in auto-value-moshi or Moshi itself. I'm hesitant to change the expectations of Moshi in the extension. I wonder if @jakewharton or @swankjesse have any thoughts on the matter.

vanniktech commented 8 years ago

@rharter there's also an issue over at moshi https://github.com/square/moshi/issues/141

swankjesse commented 8 years ago

One solution is to think of these as independent types: ReadableValue and WriteableValue.

vanniktech commented 8 years ago

I agree with your proposed terminology. Yours is a lot better. About your second concern I'm happy to send a PR to either repository as I'd like to move away from Jackson and use Moshi instead.

swankjesse commented 8 years ago

Do you need to send a PR? For your example I’m proposing this:

@AutoValue
public abstract class SendableValue {
    @Json(name = "name") String name();
    @Json(name = "foo") String foo();
}

@AutoValue
public abstract class ReceivableValue {
    @Json(name = "name") String name();
    @Json(name = "bar") String bar();
}
vanniktech commented 8 years ago

This way I'd have three classes which I'd need to potentially change if there's a new property. SendableValue, ReceivableValue and also my Model class. Every time I want to send my model to the server, I'd also need to create an instance of SendableValue class and for receiving it a ReceivableValue and then afterwards transform it back to my Model class.

With having the above mentioned feature I'd only need to make changes to my model class. Plus I'd save the complete transforming part.

david-perez commented 8 years ago

I also have the same issue.

@vanniktech Did you find a better workaround or are you currently using what @swankjesse suggested?

vanniktech commented 8 years ago

Nope I didn't find a better workaround yet though this has become less of a priority for me otherwise I probably would have pushed a version with #41 out as a fork.

vanniktech commented 8 years ago

Closing since Lazy Adapters are providing custom Adapters for these cases which also work nicely with this project.