get8848 / log4jdbc-log4j2

Automatically exported from code.google.com/p/log4jdbc-log4j2
0 stars 0 forks source link

Dump sql parameters don't work on batch statements #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Make batch statements.
2. All dump parameters log4jdbc.dump.sql.*=true. That means filtering is 
switched off.
3. For example, in log we have:
228283 [main] (19 Nov 2014 18:42:20,185) INFO  jdbc.sqlonly - batching 1 
statements:
1:  update MV_INCOMING_CALL_PROJECT set removed = 1,removalDate = '11/19/2014 
18:42:11.260',stateUUID = 'pstcimfs000080000kba2c4u01aiu8b4',state = 
'Блокированный' where UUID = 'corebofs000080000kjhtp5ub5gj4n9s'
4. Next I want to exclude update statement using log4jdbc.dump.sql.update=false
5. It doesn't work because prefix "1:   " prevent the lib to recognize that it 
is an update statement.

What is the expected output? What do you see instead?

Update statement not appeared in log, but other statements do appear.

What version of the product are you using? On what operating system?

1.16

Please provide any additional information below.

Original issue reported on code.google.com by dmitry.k...@gmail.com on 19 Nov 2014 at 1:49

GoogleCodeExporter commented 9 years ago
Yeah, I see the problem, but these parameters log4jdbc.dump.sql.* were a bad 
idea from the beginning (the original developer of log4jdbc himself said he 
thought about disabling this feature, see 
https://code.google.com/p/log4jdbc/issues/detail?id=28)

I think this could be implemented in a custom RdbmsSpecifics, or something 
similar, so that users could define what is a select statement, an update 
statement, etc. But this would require some work. Unless you could come up with 
a patch, I think this will remain a "won't fix".

Original comment by frederic...@gmail.com on 31 Jan 2015 at 11:01