[
https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-595:
----------------------------------
Affects Version/s: 10.3.0.0
10.2.1.6
Hello Mayuresh,
I had a look at this. It seems DERBY-1693 fixed this problem for [BC]lob, but
not for other data types. The fix was too specific/narrow (sorry 'bout that...).
One way to fix this, would be to implement a mechanism similar to what is found
in SQLClob.getTraceString for all data types that can be set from a stream (or
where draining the stream would cause problems). I do not know if there is a
single point of interception for this, or if we must implement the method in
each appropriate data type. It might also depend on whether we want to include
the name of the data type in the trace string.
I would suggest having a look at the type hierarchy in 'iapi.types' and see if
a clear solution stands out.
The current intent of getTraceString for streamable types, is to not drain the
stream if the data is represented as a stream. Obtaining length information in
this case is not feasible. One must also consider if the data itself should be
printed to the log, or only the length. For Clob, "CLOB(32453)" is printed if
the data is materialized, "CLOB([EMAIL PROTECTED])" otherwise.
When I applied a temporary fix to SQLLongVarbit, 'resultsetStream' passed with
statement logging enabled.
> Using derby.language.logStatementText=true can mask certain exceptions and
> lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and
> lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected)
> exceptions are raised when DVD.getString() is called, the exception gets
> eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for
> the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with
> derby.language.logStatementText=true and expected error exceptions wont be
> thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java
> uses derby.language.logStatementText=true. I'll file another bug to resolve
> this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
