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

Misleading warning in FlowLog while generating Operators using TypeConverters #1488

Closed
dave-mellors opened this issue Dec 4, 2017 · 4 comments
Milestone

Comments

@dave-mellors
Copy link

DBFlow Version: 4.1.2
Issue Kind : Question

Description:

When generating SQL involving an Operator with a TypeConverter, for example:

SQLite.select().from(Log.class).where(Log_table.insertTime.greaterThan(yesterday))

a warning message is generated in the FlowLog which details a ClassCastException with full stack trace, via
Operator.convertObjectToString(Object object, boolean appendInnerParenthesis)

The appearance of the stack trace caused me to spend some time believing that some error had occurred, whereas the final output of the method is actually correct in this case.

Would it be possible to change the log record to not include the stack trace in this instance?

@agrosner
Copy link
Owner

Its just giving you an idea of a possible problem.

                // if object type is not valid converted type, just use type as is here.

the comment should have helped you or at least seeing through debugging why it happened should explain it.
For reference, what is the type of insertTime and what is the value/type of yesterday

@dave-mellors
Copy link
Author

I am not suggesting that the warning is removed (although this is reporting the internal default behaviour, which in this case is the desired outcome), which is perfectly valid, but that the log need not contain a stack trace as it is only a warning and not an error as such. The warning could still show relevant details at that point.

The example above is just an example, not a real case, but would have been a String representation of a LocalDateTime. The resulting SQL was exactly as it should have been.

@agrosner
Copy link
Owner

ill move it up to Level.I info and put it as not a stack trace, but as the actual purpose of what is happening.

@agrosner agrosner added this to the 4.2.3 milestone Dec 19, 2017
@agrosner
Copy link
Owner

in develop.

@agrosner agrosner mentioned this issue Dec 20, 2017
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