Realm-java: Support transient keyword

[cmelchior]

From this article https://medium.com/@ffvanderlaan/realm-auto-updated-objects-what-you-need-to-know-b2d769d12d76#.hzmdv62a9

Would it make sense to allow the transient keyword and just treat any field with transient as having @Ignore? On the top of my head I cannot come with any negatives, but plenty of positives:

• transitive literally means "don't serialize this" = "Don't save to disk" = "@Ignore"
• Better support for GSON.
• Closer to language semantics instead of using custom annotations.
• Open question: Should we deprecate/remove @Ignore ?

Some good counter points here http://stackoverflow.com/questions/2154622/why-does-jpa-have-a-transient-annotation, but I'm not entirely convinced they apply to the Android world.

public class Person extends RealmObject {
  // Today
  @Ignore
  public String foo;

  // With change
  public transient String foo;
}

Thoughts @realm/java ?

TODO

• [ ] Decide if @Ignore should be deprecated
• [ ] Modify annotation processor so transient are treated as @Ignore
• [ ] Unit tests

[zaki50]

Allowing transient and treating it as @Ignore is :+1:, but I don't think we should remove @Ignore.

[cmelchior]

Merged in #4436

[Zhuinden]

Awesome!

[AntonAndreevEpam]

Awesome, but I have case where I am using transient to remove concrete field from GSON serialization and at the same moment I required that field in database. So right now that case is broken because, if there is a transient keyword on field, Realm ignores it even if I add @Required annotation

[Zhuinden]

No, you are just not using @Expose and trying to hack around it.

Use @Expose, Realm works just fine this way.

[eygraber]

Using @Expose is not the only way of doing things with GSON; it's equally valid to take the approach of including everything, and excluding unwanted fields using transient, and I'm sure that most use cases take this approach.

Realm shouldn't make interop with GSON hinge on forcing use of @Expose.

[Zhuinden]

Hmm it's been a year but I think I might have been rash; although in general I wouldn't use RealmObjects as the descriptors of a JSON API.

They are two unrelated things and it is generally a terrible idea to mix them. So whether GSON and Realm interops on the same class's transient fields as expected or not, shouldn't even be a question if there's proper separation between independent things.

[eygraber]

True, but in a lot of cases (in my experience) they end up being the same class in order to iterate quickly.

[Zhuinden]

in order to iterate quickly.

Honestly, that's a terrible excuse. You could use a live template, or write a source code file generator, or maybe just use replace regex to replace the field name with .setField(other.getField()); then tweak as necessary. I used to do this quite often (both the regex-replace and eventually a mapper generator) when I was using Realm, this wasn't a significant overhead...

But I do think that "quick" shouldn't mean "just don't think at all while you're writing code".

---

Of course, I guess you can write a GSON type adapter for each RealmObject, except now you'll have the same thing done through GSON's api rather than just an everyday regular independent mapper function.

I don't know man, I would never reuse the API schema for the DB model. I've never seen a case where they actually matched, we typically have to add an accentless normalized field for querying because of UTF-8 case insensitivity limitations.

[Zhuinden]

Actually, even if we take "best practices" out of the picture, it perfectly makes sense for Realm, a persistence solution, to treat "transient" which means "non-persistent" to be ignored field.

[eygraber]

Can I give you my boss's number? Would you like to tell him that we need to make live templates, or a source code file generator?

Sometimes things happen that are out of your control, and the project uses the same objects for the API and DB. Many times it's a PITA. Doesn't change the fact.

Considering Realm has an option for this already (@Ignore) it shouldn't add multiple ways of doing this, especially when there are other libraries out there that don't have a simple alternative.

[cmelchior]

Our driving force when designing API's are roughly this:

1) Feel as natural as pure Java as possible.
2) Try to play as nice as possible with other libraries.

In this case transient is treated as ignored by both GSON and Realm, which is also in line with the semantics offered by Java itself. Unfortunately in your case you are mixing domain models with different rules and then you will run into issues like this.

I agree with @Zhuinden that the cleanest solution is having two different models because I suspect you will run into more design issues down the line. That said, I have a lot of sympathy for your approach. It is pragmatic ... until it is not, like now.

I doubt we are going to revert our policy of making transient being ignored as a default but it would be relatively simple to add a configuration parameter to the annotation processor that would change the behavior so you can combine GSON and Realm the way you do it. It isn't something we would prioritize ourselves though, but we would be happy to accept a PR for it.

[Zhuinden]

Can I give you my boss's number? Would you like to tell him that we need to make live templates, or a source code file generator?

Your boss explicitly tells you to re-use the API schema as the local DB cache? :thinking:

When I made a source code file generator project, nobody really asked about it, I didn't need to beg for permission; I just wrote it then used it to make my life easier. Technically I was reading a Retrofit interface file, and based on that generated mappers, fetch tasks, dagger modules, by running some public static void main() in a different project. It was great, although I don't expect everyone to follow suit.

But I wasn't kidding about writing mappers with copy-pasting the fields, then using a replace regex in Android Studio to replace private [A-Za-z]+ (.)(.+); with realmObject.set\U$1\E$2(dto.get\U$1\E$2); to create your initial mappers. It seems to take less than a minute to write this regex, which means it takes less than 2 minutes to write a mapper and a separate RealmObject from the API response class. I doubt this would delay the sprint deadlines.

Though yes, if other people had already wreaked havoc on the project, coming back from there can definitely be tricky. Refactoring is always more tricky than writing new code. :thinking: