Fixed
Status Update
Comments
zt...@gmail.com <zt...@gmail.com> #2
I should probably elaborate on that a bit more here :P. The ideal case would be that data classes written in other modules work the same when consumed. A standard data class (no secondary constructors, `val` properties) works fine when in the same module. The errors produced are also pretty confusing. They'll usually give what they read from the bytecode (constructor params called "var0" or the like) and reports missing setters for fields without names of said fields.
yb...@google.com <yb...@google.com> #3
I can confirm the bug and the workaround. The same problem arises when you use a data-class from a library with @Embedded
yb...@google.com <yb...@google.com> #5
given that log, looks like kotlin again not generating proper parameter names for methods.
bo...@gmail.com <bo...@gmail.com> #6
so turns out this is not about kotlin.
does not work w/ javac either because parameter names are not part of the class signature unless compiled w/ debug.
We will need to add a new annotation to support this.
does not work w/ javac either because parameter names are not part of the class signature unless compiled w/ debug.
We will need to add a new annotation to support this.
di...@gmail.com <di...@gmail.com> #7
True on the javac bit, but for kotlin you should be able to read the parameter names from the `@Metadata` annotations (since the param names are part of the public API in kotlin). There's no public API around this today though admittedly :/
yb...@google.com <yb...@google.com> #8
actually i have a CL that makes this work for java as well but may not work for release builds (didn't try)
but it is shady, uses private APi and someday will break.
on the other hand, kotlin version seems to make sense, I'll ask kotlin folks to see if they have any plans to open it up.
but it is shady, uses private APi and someday will break.
on the other hand, kotlin version seems to make sense, I'll ask kotlin folks to see if they have any plans to open it up.
bo...@gmail.com <bo...@gmail.com> #9
we've added support for kotlin using kotlin-metadata. will go out in 1.1 alpha 2
bo...@gmail.com <bo...@gmail.com> #10
I don't think this is really fixed. Room will still always pick the no-arg constructor rather than the primary constructor if one is found, which means you can't use immutable `val` dependencies. Taken up in https://issuetracker.google.com/issues/105769985 though
yb...@google.com <yb...@google.com> #11
Or more specifically, you can't have nullable val properties (not dependencies, misspoke earlier). If I have a class with all val properties, it works fine
yb...@google.com <yb...@google.com> #12
In the next version, Room will throw by default.
This behavior can be changed by calling fallbackToDestructiveMigration in the builder.
Thanks for all the feedback.
This behavior can be changed by calling fallbackToDestructiveMigration in the builder.
Thanks for all the feedback.
Description
> If you upgrade the version but don’t provide any migrations, the database tables are dropped and your users will lose their data.
As a big fan of offensive programming, I would prefer that Realm would crash by default if schema version is upgraded without providing a migration. And a builder option to have it not crash and drop tables (current behavior) in this scenario.
Reddit discussion: