[
https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488036
]
Kristian Waagan commented on DERBY-595:
---------------------------------------
I had a look at the patch and have a few comments.
I am not sure I like the class name for the column type. This might be okay for
developers, but for users reading the log they provide little use. Could we use
the SQL type instead?
We could also consider another representation for the streams, but I can't
think of any good ones except for possibly removing the package names. The
memory location could be useful during debugging.
Here is an example of the log when inserting a CLOB with a stream and a string
of length eight into a VARCHAR column:
2007-04-11 09:20:08.854 GMT Thread[main,5,main] (XID = 3400), (SESSIONID = 0),
(DATABASE = ReproDerby1693DB), (DRDAID = null), Executing prepared statement:
insert into clobs values (?) :End prepared statement with 1 parameters begin
parameter #1: class org.apache.derby.iapi.types.SQLClob([EMAIL PROTECTED]) :end
parameter
2007-04-11 09:20:14.587 GMT Thread[main,5,main] (XID = 5010), (SESSIONID = 0),
(DATABASE = ReproDerby1693DB), (DRDAID = null), Executing prepared statement:
insert into varchars values (?) :End prepared statement with 1 parameters begin
parameter #1: class org.apache.derby.iapi.types.SQLVarchar:Length=8 :end
parameter
Next, I like to see the actual values in the log for types where this is
"suitable". The problem is defining what is suitable. Any VARCHAR up to the
maximum length? If the length of the string is less than N? Just for string
types, not binary?
I believe the patch do change the behavior. Where strings (CHAR, VARCHAR) were
printed earlier, there will now be a class name and a length.
I hope someone else can express their opinions on these issues.
Last, there are a few whitespace issues I'd like to see fixed, but I believe
they can be handled on commit if necessary. I like to have a blank line between
methods (last line of previous method and the JavaDoc/signature of the next),
and also spaces in string constructions. You may ignore these as my personal
likings, but I mention them because I mean they improve the readability of the
code.
Thanks,
> 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
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff
>
>
> 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.
