Skip to content

FieldValue.ofObj with string-like field thinks that Long is string type #64

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

Closed
lavrukov opened this issue Apr 15, 2024 · 1 comment
Closed
Assignees
Labels
bug Something isn't working

Comments

@lavrukov
Copy link
Contributor

FieldValue.ofObj((long), modelField.getJavaField()) where modelField is UUID field make a str FieldValue.

@lavrukov lavrukov added the bug Something isn't working label Apr 15, 2024
@nvamelichev nvamelichev self-assigned this Apr 15, 2024
@nvamelichev
Copy link
Collaborator

nvamelichev commented Apr 22, 2024

Making explicitly-typed methods FieldValue.of{Str,Num,Timestamp,...} has been a mistake, I'm marking them public again. You then should replace FieldValue.ofObj() calls in ExpressionParser back with explicit construction of FieldValues, e.g., a call to FieldValue.ofTimestamp() in parseDateTimeOrNumericValue(). Then you will have a FieldValue that is always a value of expected type inside (or an error if the value does not fit the type).

Implicitly-typed method FieldValue.ofObj() cannot be changed in a way compatible with custom value types. This is because custom value type can have a ValueConverter that accepts any java.lang.Object. In this (very common) case, FieldValue.ofObj(Object, JavaField) will always store the value converted by the JavaField's custom ValueConverter (because it accepts any Object!), as you can see in this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants