opened
edwardaa
username_0
To exclude a field from class serialization I create a [custom type adapter] (https://github.com/square/moshi#custom-type-adapters) to write all fields except it, but the class has many fields. 
Is there an easy way to achieve that?
Exclude fields from serialization and deserialization
issue
created
swankjesse
username_1
Use `transient` on the field declaration.

```
private String serialized;
private transient String not_serialized;
````
comment
closed
swankjesse
username_1
issue
created
edwardaa
username_0
cool, thanks.
comment
created
dimsuz
username_2
Is there a way to make this exclusion happen at the runtime? E.g. something like Gson's [ExclusionStrategy](http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/ExclusionStrategy.html)? The reason I'm asking is because I'd like to try using Moshi with Realm database. See Realm's instructions for Gson for example (they require using ExclusionStrategy to exclude some internal fields):

https://realm.io/docs/java/0.77.0/#other-libraries
comment
created
swankjesse
username_1
Not at the moment. We could support say, `@Json(include=false)` or something.
comment
created
dimsuz
username_2
Looks like it wouldn't solve it in this case. In the example on the above page `User` class inherits `RealmObject` class which would have some field to be excluded and this field is not accessible to library client and `RealmObject` itself is part of the library too, user has no option of annotating its fields with `@Json(include=false)`...
comment
created
swankjesse
username_1
I think `transient` is probably easiest. Let's stick with that.
comment
created
swankjesse
username_1
Your best bet is to write a JSON Adapter that converts a value to something that can be encoded. The wiki has examples.
comment
created
dimsuz
username_2
Yes, `transient` looks really simple and means exactly same as its documentation says :)
Ok, thanks, will play around.
comment
created
vanniktech
username_3
Would be nice if this `transient` feature could be mentioned in the README.
comment
created
swankjesse
username_1
Good idea @username_3. Done!
comment
created
Shyish
username_4
Please take into account that making a field `transient` will turn into that field not being serialized; ex: `Bundle.putSerializable(...)` won't work on that specific field.
comment
created
i-farhanp
username_5
anyone looking for kotlin alternative,it would be @Transient
comment
created
grennis
username_6
@username_5  Unfortunately @ Transient requires a backing field, so you can't do:
  @ Transient val something: String by lazy { ... }

What is the proper solution to ignore a field for Kotlin?
comment
created
miPlodder
username_7
@username_1 How to achieve it in Kotlin ?
comment
created
micHar
username_8
@username_1 it would be nice if you revisited this issue, because transient is clearly not suitable for all kotlin usages.
comment
created
hzsweers
username_9
@username_6 could you file a separate issue with a stacktrace or small sample project that reproduces it? Sounds like something we could at least give a better exception for.
comment
created
grennis
username_6
@username_9  and others, I found that you CAN use lazy properties on Moshi classes with: `@delegate:Transient` (instead of `@Transient`...) So, I think it's fine.
comment
created
chimbori
username_10
`transient` is also used by other libraries, such as [Cupboard](https://bitbucket.org/littlerobots/cupboard) for the same purpose. With two separate annotations (one for Moshi, one for Cupboard), one could mark a field for inclusion/exclusion in JSON as well as (separately) in a database table. But with the current approach of only supporting this via `transient`, Moshi makes it hard to play well with other libraries. Ideally, each library’s builder should provide a way to opt out of special treatment for `transient` and opt into annotation-based exclusion strategies.
comment
created
grennis
username_6
@username_10  I agree. Transient has too many meanings in other contexts. Moshi should have its own dedicated annotation for excluding properties.
comment