IssueTracker

My guess is an AutoValue extension is what's needed here: http://ryanharter.com/blog/2016/05/16/autovalue-extensions/

We accept pull requests! :)

> We accept pull requests! :)

Is there a public repo somewhere? I don't see any obvious repo for it in https://android.googlesource.com, and it doesn't seem to be inside https://android.googlesource.com/platform/frameworks/support.

Room supports final fields (yay!), which probably will suffice for many people with respect to this feature request.

Room supports immutability (it can use arg constructors) but does not directly support AutoValue. It is in the schedule but not high priority :/. Idk much about its internals at this stage so I'm not sure how we would implement it but should be totally doable.

Sorry we don't have the source release yet :/.

"It is in the schedule but not high priority" -- completely understandable.

"Sorry we don't have the source release yet :/." -- ah, OK, I thought perhaps with the pull request comment, that meant that there was a repo somewhere that I had overlooked.

Thanks!

Add autovalue support also means you can easily achieve parcelable by https://github.com/rharter/auto-value-parcel. Please consider support this.

AutoValue is really a handy way to ensure data integrity.

Please add AutoValue support. AutoValue is a Google library with really good benefits such as toString() , hashCode() , AutoValue.Builder , checks at creation time if @NonNull values are null, etc.

FWIW, issue 64206877 is not publicly accessible.

@Yigit: That appears to be a private ticket.  Any way we can have access to keep up with it?

Have any updates?

news?

Is there any update? This is huge for app that  absolutely enforces immutable entities.

SqlDelight has out of the box support for AutoValue.  Use it with SqlBrite and you've got *pretty good* parity with Room.  With the lack of movement on this ticket, I'd suggest at least taking a look at those if AutoValue is important to you.

Support on olways

Sorry this used to be higher priority but other features got in the way (and to be honest, androidX migration took a lot more time than we thought).

I want to make 1 thing clear though, Room does support immutable entities. One of the reasons why this ticket lost some priority is that it is specific to AutoValue, not immutability. If you are using Kotlin, data classes give you the same power and Room supports them properly. (hence, there is an easy way to achieve immutability w/ Room).

The issue in this one is that we don't have out of the box support to discover AutoValue builders.
We still plan to do this, sorry that it is taking longer than we initially communicated.

I'd like to piggy back onto this issue, because I've fun into a similar problem with immutability that does NOT involve autovalue. What I have found is either a bug or a missing feature, depending on your perspective.

Let's say I have a Kotlin data class with only `val` properties. I want to serialize this into my Room database, but I want to decorate it with a few other values, for example a timestamp so I know when it was last updated, and a userId because my database supports multiple users. Oh look! There's an annotation `@Embedded` that seems to do just want I want. I can create a new class specific to Room persistence, add the few new properties I want, and then "embed" the original object, and damn that was easy.

Oh no. Now my project won't compile. It seems that embedded objects must have public getters -- all my `val`s must now be `var`s. D:

Sigh. I guess I'll just write a new class that has _all_ the properties of the original, plus a few more, and write an extension function to transform from one to the other. Really glad Room saved me all that Sqlite boilerplate, so I now have time for Room-specific boilerplate ;-)

*public setters, not public getters