[ http://issues.apache.org/jira/browse/DERBY-1130?page=comments#action_12427597 ] Deepa Remesh commented on DERBY-1130: -------------------------------------
I was going to post a release note about the existing application impact. But based on what Dan just said, this change in the method does not look correct and maybe we need to revert it. Any thoughts on this? Other options I can think of are: 1) Move the check of connectionAttributes into getConnection method. This way we throw the exception(that we cannot set databaseName attribute on a data source) when getConnection is called. 2) Go back to the first solution (derby-1130-v1.diff) which just ensures that database name set using setConnectionAttributes does not get used by client driver. This is more like what is being done in embedded driver , i.e, we just ignore the databaseName attribute. Also, modify the error message to explicitly indicate "Derby datasource property" and thus differentiate it from databaseName "attribute". 3) other options ? Please provide feedback about how to proceed on this issue. Thanks. > Client should not allow databaseName to be set with setConnectionAttributes > --------------------------------------------------------------------------- > > Key: DERBY-1130 > URL: http://issues.apache.org/jira/browse/DERBY-1130 > Project: Derby > Issue Type: Bug > Components: Network Client > Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, > 10.1.2.2, 10.1.2.3, 10.2.0.0, 10.1.3.0, 10.1.2.4 > Reporter: Kathey Marsden > Assigned To: Deepa Remesh > Fix For: 10.2.0.0 > > Attachments: d1130-client-v1.diff, d1130-client-v1.status, > d1130-test-dataSourceReference.diff, d1130-test-dataSourceReference.status, > derby-1130-v1.diff, derby-1130-v1.status > > > Per this thread, setConnectionAttributes should not set databaseName. > http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621 > Currently this is allowed for client but should be disabled. I think it is > OK to change because we have documented that client will be changed to match > embedded for implementation defined behaviour. Hopefully its use is rare as > most folks would use the standard setDatabaseName. Still there should be a > release not when the change is made and it would be better to change it > sooner than later: > Below is the repro. > Here is the output with Client > D>java DatabaseNameWithSetConnAttr > ds.setConnectionAttributes(databaseName=wombat;create=true) > ds.getDatabaseName() = null (should be null) > FAIL: Should not have been able to set databaseName with connection attributes > Also look for tests disabled with this bug number in the test > checkDataSource30.java > import java.sql.*; > import java.lang.reflect.Method; > public class DatabaseNameWithSetConnAttr{ > public static void main(String[] args) { > try { > > String attributes = "databaseName=wombat;create=true"; > org.apache.derby.jdbc.ClientDataSource ds = new > org.apache.derby.jdbc.ClientDataSource(); > //org.apache.derby.jdbc.EmbeddedDataSource ds = new > //org.apache.derby.jdbc.EmbeddedDataSource(); > System.out.println("ds.setConnectionAttributes(" + > attributes + ")"); > ds.setConnectionAttributes(attributes); > System.out.println("ds.getDatabaseName() = " + > ds.getDatabaseName() > + " (should be null)" ); > Connection conn = ds.getConnection(); > } catch (SQLException e) { > String sqlState = e.getSQLState(); > if (sqlState != null && > sqlState.equals("XJ041")) > { > System.out.println("PASS: An exception was > thrown trying to get a connetion from a datasource after setting databaseName > with setConnectionAttributes"); > System.out.println("EXPECTED EXCEPTION: " + > e.getSQLState() > + " > - " + e.getMessage()); > return; > } > while (e != null) > { > System.out.println("FAIL - UNEXPECTED > EXCEPTION: " + e.getSQLState()); > e.printStackTrace(); > e = e.getNextException(); > } > return; > } > System.out.println("FAIL: Should not have been able to set > databaseName with connection attributes"); > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
