Adding support to AutoValue.Id.

[rdtorres]

This new annotation should be used when an autoValue does not want to use all its fields in the equals() and hashcode() method. So, the autovalue bean can simple annotate all fields that should be used to unique identify that bean.

Let me know if you like it, so I can add more JUnit tests to cover edge cases.

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[rdtorres]

I used another email account to submit this pull request. How can I associate this other account to my CLA account ?

[googlebot]

CLAs look good, thanks!

[rdtorres]

This change has nothing to do with the commit. But I fixed it because checkstyle was complaining about it.

[eamonnmcmanus]

We explicitly say in the documentation that we don't support fields that don't participate in equals and hashCode. If we did want to do so, this would certainly be one way of going about it. In that case I think we would also want the ability to say, independently, whether a field appears in toString.
Pinging @kevinb9n.

[rdtorres]

I've read the documentation and I know that auto-value does not support it.
In fact, this is the main reason behind this pull request: Add to support
to it =). The toString method can also follow a similar approach where an
annotation like "Autovalue.Printable" would indicate which fields should be
printed or not. Again, these annotations are extra, non-mandatory
annotations. So, default auto-model behaviour will be exactly the same as
we have nowadays...

Let me know what do you guys think.

On Tue, Mar 31, 2015 at 2:03 PM, Éamonn McManus [email protected]
wrote:

We explicitly say in the documentation
https://github.com/google/auto/tree/master/value#derived-fields that we
don't support fields that don't participate in equals and hashCode. If we
did want to do so, this would certainly be one way of going about it. In
that case I think we would also want the ability to say, independently,
whether a field appears in toString.
Pinging @kevinb9n https://github.com/kevinb9n.

Reply to this email directly or view it on GitHub
#212 (comment).