Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scala 2.11 @transient's are null #187

Open
MaXaMaR opened this issue Jul 18, 2016 · 6 comments
Open

Scala 2.11 @transient's are null #187

MaXaMaR opened this issue Jul 18, 2016 · 6 comments

Comments

@MaXaMaR
Copy link

MaXaMaR commented Jul 18, 2016

After loading of object from DB all @transient val fields are null.
lazy val fields throw
java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.Byte on access.

I think it has something to do with scala 2.11 because it seems that similar issues were fixed before.

@MaXaMaR MaXaMaR changed the title Scala 2.11 @transient\s are null Scala 2.11 @transient's are null Jul 18, 2016
@fwbrasil
Copy link
Owner

After loading of object from DB all @transient val fields are null.

That's expected, since they are transient, they aren't persisted.

lazy val fields throw
java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.Byte on access

That's interesting, could you share an isolated example of code that reproduces the issue?

@MaXaMaR
Copy link
Author

MaXaMaR commented Jul 18, 2016

That's expected, since they are transient, they aren't persisted.

But shouldn't they be reevaluated after select?

@fwbrasil
Copy link
Owner

But shouldn't they be reevaluated after select?

No, unless it's lazy.

@MaXaMaR
Copy link
Author

MaXaMaR commented Jul 18, 2016

No, unless it's lazy.

So what is the reason to have @transient vals at all? After select they are unusable. I think this is a bug.
Even if @transient var can be changed it is not normal that it is handling null.

@MaXaMaR
Copy link
Author

MaXaMaR commented Jul 18, 2016

I've found more: all transient lazy val fields throw that exception but only if there is overridden transient lazy val toString. If it is tried to access transient lazy val field outside of transaction then this exception is thrown, not no transaction exception. It is also strange that it is required to have an active transaction to access lazy val field that already has all needed data.
activate-transient-lazy-val-fail.zip

@MaXaMaR
Copy link
Author

MaXaMaR commented Jul 18, 2016

Okay, I'm correct, transient val fields got reevaluated on select. Can't reproduce that first part.
Now transient lazy vals. Transient lazy vals throw that ex if in the same class some transient lazy val uses other transient lazy val. Seems like substitution doesn't work correctly.
activate-transient-lazy-val-fail.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants